linux-kernel - Re: ext2 + -osync: not as easy as it seems

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, 16 Feb 2009 13:09:25 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Jan Kara <jack@...e.cz>, Theodore Tso <tytso@....edu>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: ext2 + -osync: not as easy as it seems

On Thu, Feb 12 2009, Eric Sandeen wrote:
> Jens Axboe wrote:
> > On Wed, Jan 14 2009, Jan Kara wrote:
> >>> I'm not sure what you mean; if the barrier operation isn't flushing
> >>> all of the caches all the way out to the iron oxide, it's not going to
> >>> be working properly no matter where it is being called, whether it's
> >>> in ext4_sync_file() or in jbd2's journal_submit_commit_record().
> >>   Well, I thought that a barrier, as an abstraction, only guarantees that
> >> any IO which happened before the barrier hits the iron before any IO which
> >> has been submitted after a barrier. This is actually enough for a
> >> journalling to work correctly but it's not enough for fsync() guarantees.
> >> But I might be wrong...
> > 
> > It also guarentees that when you get a completion for that barrier
> > write, it's on safe storage. Think of it as a flush-write-flush
> > operation, in the presence of write back caching.
> 
> (sorry for chiming in so late)
> 
> Jens, isn't this just the way it's implemented today?  At some point
> couldn't a barrier bio simply be a reordering barrier that the storage
> can use when destaging the write cache, rather than the heavy-handed
> flush-write-flush we have today?
> 
> I guess it's a question of the intended semantics of a barrier bio, vs.
> today's implementation based on current hardware functionality...

Right, the current implementation is largely an artefact of what we can
do with todays hardware. It would be quite reasonable to decouple the
flush from the reordering, if we were able to support that on the
hardware side.

-- 
Jens Axboe

--
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/