Am Montag, 7. Mai 2012 schrieb Daniel Pocock: > > Possibly the older disk is lying about doing cache flushes. The > > wonderful disk manufacturers do that with commodity drives to make > > their benchmark numbers look better. If you run some random IOPS > > test against this disk, and it has performance much over 100 IOPS > > then it is definitely not doing real cache flushes. […] > I would agree that is possible - I actually tried using hdparm and > sdparm to check cache status, but they don't work with the USB drive > > I've tried the following directly onto the raw device: > > dd if=/dev/zero of=/dev/sdc1 bs=4096 count=65536 conv=fsync > 29.2MB/s Thats no random I/O IOPS benchmark, > and iostat reported avg 250 write/sec, avgrq-sz = 237, wkB/s = 30MB/sec but a sequential workload that gives the I/O scheduler oppurtunity to combine write requests. Also its using pagecache, as conv=fsync only includes the fsync() at the end of dd´ing. > I tried a smaller write as well (just count=1024, total 4MB of data) > and it also reported a slower speed, which suggests that it really is > writing the data out to disk and not just caching. I think an IOPS benchmark would be better. I.e. something like: /usr/share/doc/fio/examples/ssd-test (from flexible I/O tester debian package, also included in upstream tarball of course) adapted to your needs. Maybe with different iodepth or numjobs (to simulate several threads generating higher iodepths). With iodepth=1 I have seen 54 IOPS on a Hitachi 5400 rpm harddisk connected via eSATA. Important is direct=1 to bypass the pagecache. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
