linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Drokin <green@linuxhacker.ru>
To: linux-ext4@vger.kernel.org
Cc: Alex Zhuravlev <Alex.Zhuravlev@Sun.COM>,
	Andreas Dilger <adilger@Sun.COM>
Subject: Potential data consistency issue with ASYNC_COMMIT feature
Date: Fri, 11 Dec 2009 01:45:09 -0500	[thread overview]
Message-ID: <FA695DF7-1D78-471A-A527-0079C045AF09@linuxhacker.ru> (raw)

Hello!

   I think ext4 ASYNC_COMMIT feature is potentially pretty unsafe 
   when write-back cache is enabled on the device.
   Since no barriers are ever done with this feature even if
   the barriers are enabled, we might end up in the situation
   where we write the journal blocks, then commit block, they 
   hit the device write-back cache, after that actual metadata
   blocks would be allowed to go to disk and eventually they will.

   In the end the device might decide to reorder some of the
   actual metadata updates in front of journal updates and
   if metadata updates will hit the disk and a power or other
   failure occurs after that, we have inconsistent filesystem
   as a result.

   I do not see an easy way to remedy the problem in this case
   other than to insert empty barrier after the commit block
   and wait for it completion, but I think that would negate
   the entire gain from this feature. I wish we actually had
   real ordered writes implemented, not just barrier/FUA
   sent to the device before every ordered buffer.

   Am I missing something?

   Thanks.

Bye,
    Oleg

             reply	other threads:[~2009-12-11  8:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-11  6:45 Oleg Drokin [this message]
2009-12-11  7:14 ` Potential data consistency issue with ASYNC_COMMIT feature Oleg Drokin
2009-12-11 16:01   ` Eric Sandeen
2009-12-11 20:52   ` tytso
2009-12-16 20:33     ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FA695DF7-1D78-471A-A527-0079C045AF09@linuxhacker.ru \
    --to=green@linuxhacker.ru \
    --cc=Alex.Zhuravlev@Sun.COM \
    --cc=adilger@Sun.COM \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).