Journal async commit broken for data=ordered?

Journal async commit broken for data=ordered?

[Jan Kara]

  Hello,

  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?

								Honza

Re: Journal async commit broken for data=ordered?

[Andreas Dilger]

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

Re: Journal async commit broken for data=ordered?

[Jan Kara]

On Tue 14-02-12 13:56:30, Andreas Dilger wrote:
> 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.
  Umm, I don't see how that would really make difference. Unless you flush
disk's caches you can never be sure data made it to disk. And you must make
sure data is on disk before anyone has a chance to see transaction writing
these data fully written into the log.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR