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

[Martin Steigerwald <Martin@lichtvoll.de>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html