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]
Message-Id: <15A0337B-5C65-4C36-9AD9-BE5D0E8EF812@dilger.ca>
Date:	Tue, 14 Feb 2012 13:56:30 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Jan Kara <jack@...e.cz>
Cc:	linux-ext4@...r.kernel.org, Ted Tso <tytso@....edu>
Subject: Re: Journal async commit broken for data=ordered?

On 2012-02-14, at 8:55 AM, Jan Kara wrote:
>  I've just realized that JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT breaks
> guarantees of data=ordered mode in ext4. The problem is that async commit
> code assumes that when a checksum of a transaction in the journal matches,
> all necessary data is on disk. This is true for metadata but need not be so
> for data - the whole transaction may be correctly on pernament storage
> while some data is still sitting in drive's caches. Thus if a power failure
> happens at that moment, we have broken guarantees of data=ordered mode.
> Seeing that async commit code isn't used by default anyway (I remember
> there used to be some problems with it), shouldn't we just rip it out?

A better long-term solution would be to submit the block IO in advance of
marking the metadata dirty, so the data is safe on disk before the journal
becomes involved.  That would also avoid the problem of entangling the
journal commit latency with IO waiting to be flushed to disk.

Cheers, Andreas





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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ