Re: ext4, barrier, md/RAID1 and write cache

Martin Steigerwald
2012-05-07T18:59:45Z

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