Pv - measure drive write-speeds...

[mikewalsh]

Evening, guys'n'gals.

Ran across this earlier this evening; 'twas mentioned in a thread over at LinuxQuestions.org, about why somebody's drive read/write speeds had fallen right off in a RAID setup they were attempting to prepare for use.

"pv" is a handy wee utility for measurement of data movement through a 'pipe'. An example was given, as below:-

Code: Select all

dd if=/dev/zero | pv | dd of=/dev/sdx

.....where /dev/sdx will be the drive you want to 'test'.

(For Quirky64, I had to track down an age-related version at /ubuntu/pool, but the 'buntu Pups (and DPups, too) should all have this in the repos already.)

All the example above does is to 'pipe' the output of a 'dummy', or 'ghost' file through "pv", then out to whatever drive - flash, SDcard, external USB HDD, etc - you wish to test the write speed for. Nothing actually gets written at all, but you get

• total data moved

• time elapsed

• data transfer rate

• a 'progress bar'

....all in the terminal. This thing has a lot of options, as shown here:-

https://linux.die.net/man/1/pv

....but entering the command by itself includes the '--switches' for those functions listed above by default. It's just a handy way to measure drive write speed in the terminal.....like this:-

Shouldn't be too hard to script a wee GUI for it, I wouldn't have thought...

Mike.

[williams2]

As far as I know, that will completely erase /dev/sdd including all partitions, boot loader, mbr, partition tables, etc.

I use this to erase the free space of a drive. It displays the write speed while it runs.

Code: Select all

dd status=progress if=/dev/zero of=/mnt/home/dd.bin
sync
sync
rm /mnt/home/dd.bin
sync

This will erase the free space in a save file (useful before zipping a backup save file.)

Code: Select all

dd status=progress if=/dev/zero of=/root/dd.bin
sync
sync
rm /root/dd.bin
sync

This assumes the dd.bin file will not be larger than the largest file size that the file system supports (eg fat32)

[Clarity]

Both of these are excellent "at-a-glance" visual of a write operation. The "fly-in-the-milk" is the I/O subsystem as it can/does mask operations that can/does impact the visuals as the subsystem can reflect completion even though the actual operation may still be in transit; hence "sync" terminal command.

Notwithstanding, it does give good representation of the operation's timing. Same steps, similarly, could be applied to read operations.

I prefer to use a file of a specific size as well as a common blocksize as a means of measuring a unit's performance. This is especially needed as some devices have monitors active in their controllers that are active and does/can impact performance once an operation is active.

Code: Select all

# time dd if=some-filesize.iso of=/dev/sdd blksize=1M
# time sync

This thread gives rise to the need for a testing utility that will "record" the performance(s) of the multiple USB sticks one has. That utility would need to record the physical port along with the mounted USB stick. This is because of 2 distinct things we are faced with in the modern PC world: Port performances are DIFFERENT and USB/SDD/HDD/sdcards manufacturers units are different on these ports and/or if USB hubs are intermixed.

For me, this has become a "cavalcade of sports" in all of the I/O units I use daily,

If anyone knows of a utility like this that spits out a performance entry into a file showing these items: Cinebench comes to mind, for example.

[williams2]

To be absolutely clear:

All the example above does is to 'pipe' the output of a 'dummy', or 'ghost' file through "pv", then out to whatever drive - flash, SDcard, external USB HDD, etc - you wish to test the write speed for. Nothing actually gets written at all,

AFAIK, in the example above, zeros are written to the device /dev/sdd until the device is completely erased, until all bytes are overwritten with zeros.

/dev/sdd will be COMPLETELY ERASED.
The MBR will be COMPLETELY ERASED.
The partition table will be COMPLETELY ERASED.
All partitions will be COMPLETELY ERASED.
All data in the partitions will be COMPLETELY ERASED.
All file systems in the partitions will be COMPLETELY ERASED.

AFAIK, the statement "Nothing actually gets written at all" is not true.

If I am wrong, someone please say that I am wrong.