linux-kernel - Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes

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:	Fri, 23 May 2008 14:33:56 -0400
From:	Ric Wheeler <ricwheeler@...il.com>
To:	Theodore Tso <tytso@....edu>, Chris Mason <chris.mason@...cle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	jamie@...reable.org, Ric Wheeler <rwheeler@...hat.com>,
	jbacik@...hat.com
Subject: Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes

Just a couple of comments about barriers that might be worth throwing in 
the mix.

 From what I have seen, running with barriers is almost always a win 
over running with write cache disabled for medium to large files (large 
files with a S-ATA drive go about twice as fast in my testing).

For very small files, running with the barrier or disabling the write 
cache are a lot closer in performance.

When we are looking for ways to batch, it is also critical to keep in 
mind the latency of the storage. The current ext3 transaction batching 
code makes running multi-threaded workloads on high speed media (like 
non-volatile disk arrays) run much slower.   (Josef had some patches 
which helped fix this in a similar way that XFS deals with this.)

One other note is that moving to a FLASH based device will not make the 
issue of barriers go away since (most? all?) FLASH parts you are likely 
to see have their own write cache which is used to buffer up writes in 
order to make the erase cycle less painful. That means that we have a 
fairly large *volatile* write cache which needs to be flushed/controlled 
just like we do with S-ATA/SCSI/etc ;-)

ric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/