On Saturday, November 13, 2010 01:08:12 pm Michael Miles wrote: > Lamar Owen wrote: > > [r...@migration ~]# ./seeker /dev/sdb3 > > Seeker v2.0, 2007-01-15, > > http://www.linuxinsight.com/how_fast_is_your_disk.html > > Benchmarking /dev/sdb3 [7012MB], wait 30 > > seconds.............................. > > Results: 21459 seeks/second, 0.05 ms random access time > > [r...@migration ~]#
> I have run all these tests and I have to say that Seeker is not a valid > test to show speeds of these disks > I ran hdparm and it shows the lvm to be a bit slower but not a lot. > With Seeker it shows a large difference because of the area on the disk > being tested > That's quite a difference on sdb3 by the way. It's amazing how much > speed a filesystem takes away from a disk The Seeker and hdparm -t results have nothing to do with the filesystem being there or not; if I run seeker on /dev/sdb or /dev/sdb1 or /dev/sdb3 I'm running it against the device; the presence or absence of a filesystem makes no difference. With LVM running it against the raw logical volume device (in my examples, the volume group was benchtest, and the logical volume was 50g, making the device node /dev/benchtest/50g) does the same thing, and doesn't have anything to do with the filesystem. The bonnie++ results do, however, reflect the filesystem performance, since bonnie++ is writing and reading files on the filesystem instead of raw device. What does make a difference is the size of the device being tested, in terms of cylinders or blocks. If the partition is 1000 cylinders, a true random seek will seek to cylinders between the start and the start+1000; if it's a 100 cylinder partition, it will seek between the start and the start+100, one-tenth of the distance, and thus it should produce an average seek that is quite a bit smaller than the partition with 1000 cylinders. Thanks to modern ZBR (zone bit recording) drives, ten times the number of blocks does not necessarily translate to ten times the number of cylinders (for more information about ZBR and what that means for disks, see http://en.wikipedia.org/wiki/ZBR for details. In any case, I've set up LVM on /dev/sdb3 (/dev/bench2/7g is the logical volume's device node), and here's some more seeker and hdparm -t "results" for your enjoyment: +++++++++++++++++++++++++++ Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sdb3 [7012MB], wait 30 seconds............................. Results: 23546 seeks/second, 0.04 ms random access time [r...@migration ~]# ./seeker /dev/bench2/7g Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/bench2/7g [7012MB], wait 30 seconds.............................. Results: 37116 seeks/second, 0.03 ms random access time [r...@migration ~]# hdparm -t /dev/bench2/7g /dev/bench2/7g: Timing buffered disk reads: 852 MB in 3.00 seconds = 283.65 MB/sec [r...@migration ~]# hdparm -t /dev/sdb3 /dev/sdb3: Timing buffered disk reads: 774 MB in 3.01 seconds = 257.53 MB/sec [r...@migration ~]# +++++++++++++++++++++++++++ Of course, the fact that that entire partition can fit in the kernel's cache makes a difference here in the Seeker results; the hdparm -t (just a big sequential read, that's all) just shows that the array is very good at caching and doing readahead. So I tend to trust bonnie++'s results more, since it takes pains to take the cache out of the equation. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
