linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Frank Mayhar <fmayhar@google.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] Make non-journal fsync work properly.
Date: Tue, 8 Sep 2009 01:06:14 -0400	[thread overview]
Message-ID: <20090908050614.GA10477@mit.edu> (raw)
In-Reply-To: <1252119300.23871.7.camel@bobble.smo.corp.google.com>

On Fri, Sep 04, 2009 at 07:55:00PM -0700, Frank Mayhar wrote:
> Teach ext4_write_inode() and ext4_do_update_inode() about non-journal
> mode:  If we're not using a journal, ext4_write_inode() now calls
> ext4_do_update_inode() (after getting the iloc via ext4_get_inode_loc())
> with a new "do_sync" parameter.  If that parameter is nonzero
> ext4_do_update_inode() calls sync_dirty_buffer() instead of
> ext4_handle_dirty_metadata().

Hi Frank,

The problem with this patch is that it's only safe to call
sync_dirty_buffer() if we are not journalling.  If we are using the
journal, we must *not* call sync_dirty_buffer(), but instead must use
jbd2_journal_dirty_metadata().

The problem is that there are paths where ext4_do_update_inode() can
get called with do_sync==1, even when journalling is enabled.
Specifically, if ext4_write_inode() is called with wait==1, wait is
passed to ext4_do_update_inode() as do_sync, and then when a journal
is present, we will end up calling sync_dirty_buffer(), which means we
will be writing out the modified metadata *before* the transaction has
committed.

If you try using your patch with journalling enabled, and you try
doing some power fail testing, my code inspection leads me to believe
with 99% certainty that the filesystem will be corrupted as a result.

I think what you need to do instead is to add an extra parameter
do_sync to ext4_handle_dirty_metadata(), and continue to call
ext4_handle_dirty_metadata.  However in code paths where we will later
force a commit to guarantee that the metadata has been written out
(i.e., in the fsync() code path), ext4_handle_dirty_metadata() should
be called with the new do_sync parameter set to 1.

Does that make sense?

						- Ted

  reply	other threads:[~2009-09-08  5:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-05  2:55 [PATCH] Make non-journal fsync work properly Frank Mayhar
2009-09-08  5:06 ` Theodore Tso [this message]
2009-09-08 14:57   ` Curt Wohlgemuth
2009-09-08 21:41     ` Theodore Tso
2009-09-08 15:41   ` Frank Mayhar
2009-09-08 22:05     ` Theodore Tso
2009-09-08 22:39       ` Frank Mayhar
2009-09-09 17:34       ` [PATCH] ext4: Make non-journal fsync work properly. REPOST Frank Mayhar
2009-09-10  2:55         ` Theodore Tso
2009-09-14 16:54         ` Aneesh Kumar K.V
2009-09-14 17:43           ` Frank Mayhar
2009-09-26  0:39         ` [PATCH] ext4: Make non-journal fsync work properly. (Version 3) Frank Mayhar
2009-09-29 14:09           ` Theodore Tso
2009-09-10  6:57 ` [PATCH] Make non-journal fsync work properly Aneesh Kumar K.V
2009-09-10 15:33   ` Frank Mayhar
2009-09-10 19:45     ` Theodore Tso

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=20090908050614.GA10477@mit.edu \
    --to=tytso@mit.edu \
    --cc=fmayhar@google.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).