I’ve made an interesting discovery regarding the significant decline in copying/pasting speed, when transferring large amounts of data - the copying speed issue now appears to be solved...
As mentioned in the first post of this thread, I was copying 1.6TB of video files (3000+ files @ average size ~ 500MB) from a 4TB USB Seagate drive (ntfs format) to a 4TB USB Samsung drive (ext4 format). Speeds plummeted from an initial high of around 120-130 MB/s to less than 30 MB/s, resulting in a very significant increase in the time for data transfer to reach completion.
Investigation 1.
First, I wanted to check whether copying from files from a drive with an ntfs format to one with an ext4 format was the culprit. I had a second 4TB USB Seagate drive (also ntfs formatted). I found no slowdown in speed when copying between USB nfts drives (e.g. speeds remained at 110 to 130 MB/s) throughout the 4 hours it took to copy the 1.6TB. However, following this observation, I was left unsure whether this was a disk formatting issue or a difference in drive make/model influencing the outcome, i.e. behaviour of Seagate vs. Samsung – so, roll on to Investigation 2 below...
Investigation 2.
I then changed the format of the Samsung drive, from ext4 to nfts. If the copy/paste slowdown I observed initially is due to a difference in drive format between ‘donor’ and ‘receiver’ drive, then there should be no slowdown when copying from Seagate (ntfs) to Samsung (ntfs) – and that’s exactly what I subsequently observed. Speeds remained high (110 to 130 MB/s) taking around 4 hours to transfer 1.6TB of data, as I observed with the previous Seagate (ntfs) to Seagate (ntfs) copying/pasting.
Conclusion.
The observations above indicate that the speed of copying/pasting a large amount of data, directly from one USB drive to another, is influenced significantly by the drive format. To maintain high copying/pasting speeds throughout, both USB drives should have the same format, i.e. ntfs in the above case (or ext4 drives, observation of the 6 July 2017). Conversely, a very significant reduction in data transfer speed will occur if the drives have different formats, i.e. in the above case with a ‘donor’ drive = ntfs, and ‘recipient’ drive = ext4.
In view of the above discovery, I’ll therefore now mark this thread as solved
Regards
Mike
As mentioned in the first post of this thread, I was copying 1.6TB of video files (3000+ files @ average size ~ 500MB) from a 4TB USB Seagate drive (ntfs format) to a 4TB USB Samsung drive (ext4 format). Speeds plummeted from an initial high of around 120-130 MB/s to less than 30 MB/s, resulting in a very significant increase in the time for data transfer to reach completion.
Investigation 1.
First, I wanted to check whether copying from files from a drive with an ntfs format to one with an ext4 format was the culprit. I had a second 4TB USB Seagate drive (also ntfs formatted). I found no slowdown in speed when copying between USB nfts drives (e.g. speeds remained at 110 to 130 MB/s) throughout the 4 hours it took to copy the 1.6TB. However, following this observation, I was left unsure whether this was a disk formatting issue or a difference in drive make/model influencing the outcome, i.e. behaviour of Seagate vs. Samsung – so, roll on to Investigation 2 below...
Investigation 2.
I then changed the format of the Samsung drive, from ext4 to nfts. If the copy/paste slowdown I observed initially is due to a difference in drive format between ‘donor’ and ‘receiver’ drive, then there should be no slowdown when copying from Seagate (ntfs) to Samsung (ntfs) – and that’s exactly what I subsequently observed. Speeds remained high (110 to 130 MB/s) taking around 4 hours to transfer 1.6TB of data, as I observed with the previous Seagate (ntfs) to Seagate (ntfs) copying/pasting.
Conclusion.
The observations above indicate that the speed of copying/pasting a large amount of data, directly from one USB drive to another, is influenced significantly by the drive format. To maintain high copying/pasting speeds throughout, both USB drives should have the same format, i.e. ntfs in the above case (or ext4 drives, observation of the 6 July 2017). Conversely, a very significant reduction in data transfer speed will occur if the drives have different formats, i.e. in the above case with a ‘donor’ drive = ntfs, and ‘recipient’ drive = ext4.
In view of the above discovery, I’ll therefore now mark this thread as solved
Regards
Mike
64bit OS (32-bit on Samsung[i] netbook) installed in [i]Legacy mode on MBR-formatted SSDs (except pi which uses a micro SDHC card):
2017 - Raspberry pi 3B (4cores) ~ [email protected] - LibreElec, used for upgrading our Samsung TV (excellent for the task)
2012 - Lenovo G580 2689 (2cores; 4threads] ~ [email protected] - LL3.8/Win8.1 dual-boot (LL working smoothly)
2011 - Samsung NP-N145 Plus (1core; 2threads) ~ Intel Atom [email protected] - LL 3.8 32-bit (64-bit too 'laggy')
2008 - Asus X71Q (2cores) ~ Intel [email protected] - LL4.6/Win8.1 dual-boot, LL works fine with kernel 4.15
2007 - Dell Latitude D630 (2cores) ~ Intel [email protected] - LL4.6, works well with kernel 4.4; 4.15 doesn't work
2017 - Raspberry pi 3B (4cores) ~ [email protected] - LibreElec, used for upgrading our Samsung TV (excellent for the task)
2012 - Lenovo G580 2689 (2cores; 4threads] ~ [email protected] - LL3.8/Win8.1 dual-boot (LL working smoothly)
2011 - Samsung NP-N145 Plus (1core; 2threads) ~ Intel Atom [email protected] - LL 3.8 32-bit (64-bit too 'laggy')
2008 - Asus X71Q (2cores) ~ Intel [email protected] - LL4.6/Win8.1 dual-boot, LL works fine with kernel 4.15
2007 - Dell Latitude D630 (2cores) ~ Intel [email protected] - LL4.6, works well with kernel 4.4; 4.15 doesn't work