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.
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.
You can use
time
to measure the time used by thecp
command itself writing, and after that forsync
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:
Writing to a USB 3 pendrive:
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.