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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.