From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Curt Wohlgemuth <curtw@google.com>, linux-ext4@vger.kernel.org
Subject: Re: ext4: Can we talk about bforget() and metadata blocks
Date: Sat, 12 Sep 2009 20:30:36 +0530 [thread overview]
Message-ID: <20090912150036.GA13906@skywalker.linux.vnet.ibm.com> (raw)
In-Reply-To: <20090910185826.GC23700@mit.edu>
On Thu, Sep 10, 2009 at 02:58:26PM -0400, Theodore Tso wrote:
> On Thu, Sep 10, 2009 at 09:54:35PM +0530, Aneesh Kumar K.V wrote:
> >
> > But how would it work for fsync ? I mean
> >
> > I would expect for no journal mode ext4_sync_file should be doing
> > simple_fsync(). That should be forcing the metadata buffer_heads
> > via sync_mapping_buffers. And if we reuse these meta buffers we
> > drop them the inode->mapping->private_list using bforget.
> >
> > But I don't see any of the above in code
>
> Aneesh, you're addressing a different problem than the one that Curt
> were trying to deal with this patch. The problem we are worry about
> is one where an inode's extent tree or indirect blocks are modified
> right before the inode is deleted, and then one or more of those
> metadata blocks get reallocated and written right away (most likely
> this will happen via an O_DIRECT write), and then, because we didn't
> use bforget(), the dirty metadata block in the buffer cache would get
> written out, overwriting the O_DIRECT block.
>
> What you're worrying about, is a different issue. You're concerned
> about the fact that since we are not associating an inode's extent
> tree or indirect blocks with the inode, those blocks won't get forced
> out to disk on an fsync() in ext4 no-journal mode. This may not be a
> big deal for applications which expect to recover from an unclean
> using mke2fs (and thus probably don't use fsync in any case), but
> here's a patch to deal with the problem you've raised.
>
> - Ted
>
> commit 417cf58253fbf3e36df7b3aca11c120e8367f5e6
> Author: Theodore Ts'o <tytso@mit.edu>
> Date: Thu Sep 10 14:58:02 2009 -0400
>
> ext4: Assure that metadata blocks are written during fsync in no journal mode
>
> When there is no journal present, we must attach buffer heads
> associated with extent tree and indirect blocks to the inode's
> mapping->private_list so that fsync() will write out the inode's
> metadata blocks. This is done via mark_buffer_dirty_inode().
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
> index ecb9ca4..6a94099 100644
> --- a/fs/ext4/ext4_jbd2.c
> +++ b/fs/ext4/ext4_jbd2.c
> @@ -89,7 +89,10 @@ int __ext4_handle_dirty_metadata(const char *where, handle_t *handle,
> ext4_journal_abort_handle(where, __func__, bh,
> handle, err);
> } else {
> - mark_buffer_dirty(bh);
> + if (inode && bh)
> + mark_buffer_dirty_inode(bh, inode);
> + else
> + mark_buffer_dirty(bh);
> if (inode && inode_needs_sync(inode)) {
> sync_dirty_buffer(bh);
> if (buffer_req(bh) && !buffer_uptodate(bh)) {
>
This does add the meta data buffer_head to the inode->mapping->private_list.
But ext4_sync_file is not writing them. I guess we need to call sync_mapping_buffers
for no-journal mode in ext4_sync_file
-aneesh
next prev parent reply other threads:[~2009-09-12 15:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6601abe90909091029s74465ebave932987e5fdf93ba@mail.gmail.com>
[not found] ` <20090909225429.GB24951@mit.edu>
[not found] ` <6601abe90909091707s1df9e71bvb4551772dc4917cb@mail.gmail.com>
2009-09-10 1:35 ` ext4: Can we talk about bforget() and metadata blocks Theodore Tso
2009-09-10 6:54 ` Aneesh Kumar K.V
2009-09-10 15:46 ` Curt Wohlgemuth
2009-09-10 16:24 ` Aneesh Kumar K.V
2009-09-10 18:58 ` Theodore Tso
2009-09-11 17:21 ` Aneesh Kumar K.V
2009-09-11 17:36 ` Curt Wohlgemuth
2009-09-11 18:08 ` Theodore Tso
2009-09-11 18:15 ` Theodore Tso
2009-09-12 15:00 ` Aneesh Kumar K.V [this message]
2009-09-12 17:59 ` Theodore Tso
2009-09-10 15:55 ` Curt Wohlgemuth
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=20090912150036.GA13906@skywalker.linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=curtw@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).