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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 May 2012 20:59:10 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	Daniel Pocock <daniel@...ock.com.au>
Cc:	Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: ext4, barrier, md/RAID1 and write cache

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