1

I have been trying to benchmark how long it takes to read from and write to the entire available space in the FAT filesystem on a 3.5" floppy disk. Reading wasn't much of an issue. As long as the file has not been read prior to the test, I can simply run time cp /media/user/disk/file .. However, writing is proving more troublesome.

If I use cp as with reading, I get a result of near-zero. The command finishes and the drive keeps writing for the next 45 seconds or so. I also tried using dd if=/dev/urandom of=/media/user/disk/file bs=1457664 count=1 to generate random data on the fly to put on the disk but with the same result. The final solution I tried was pv file > /media/user/disk/file, again with the same result, just presented differently. At least I found the claimed write speed of 192MiB/s amusing.

I doubt it makes a great deal of difference with something like this, but I am running Ubuntu 18.04 x64 MATE. The drive uses USB for power and data transfer.

spacer GIF
  • 317
  • You could try to reduce the write buffer first: https://unix.stackexchange.com/questions/292024/how-to-reduce-linux-write-buffer-for-removable-devices After that, you could try to fill the buffer with garbage first (dd with the exact amount) and then run a timed second command with the actual test. Not 100% accurate, but maybe closer. – G Trawo Jul 06 '18 at 15:02
  • Another option: https://askubuntu.com/questions/5051/how-to-switch-off-caching-for-usb-device-when-writing-to-it With this you can turn off the write cache completely for a mounted drive. – G Trawo Jul 06 '18 at 15:08
  • Did you try rsyncwith -n option and -v ? – abu_bua Jul 06 '18 at 16:08

2 Answers2

3

Linux extensively uses buffer memory to read/write files. Thus, a write to a drive may appear to be finished earlier, while in reality, linux continue to commit the data to the drive. To flush the buffer to disk, one can use the "sync" command. Thus, a command such as time sh -c "cp /media/user/disk/file .. && sync" would provide a better idea of the real time needed to write the copy fully to the drive.

The construct with "sh" is needed because the command time only supports a single command as its argument.

vanadium
  • 88,010
2

You can use time to measure the time used by the cp command itself writing, and after that for sync to flush the buffer, and outside those to measure the total time. See the following examples.

Writing to a hard disk drive connected via SATA:

$ time bash -c 'time cp ubuntu-18.04-desktop-amd64.iso /media/multimed-2/ttt && time sync;echo -e "\n----------\ntotal time"'

real    0m23,207s
user    0m0,009s
sys 0m3,908s

real    0m1,328s
user    0m0,000s
sys 0m0,006s

----------
total time

real    0m24,538s
user    0m0,012s
sys 0m3,914s

Writing to a USB 3 pendrive:

$ sudo time bash -c 'time -p cp ubuntu-18.04-desktop-amd64.iso /mnt/sd1/usbdata/ttt && time sync;echo -e "\n----------\ntotal time"'
[sudo] password for sudodus: 

real    0m55,390s
user    0m0,029s
sys 0m5,279s

real    0m17,595s
user    0m0,000s
sys 0m0,003s

----------
total time
real 72.98
user 0.03
sys 5.28

Notice that there is much more time for flushing the buffers when writing to the pendrive, but also the time for the copy command increases.

bc can calculate the copying speed from the file size and the total time.

$ bc
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
scale=2
1921843200/24.538/10^6
78.32
1921843200/72.98/10^6
26.33
quit
$
sudodus
  • 46,324
  • 5
  • 88
  • 152