From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Curt Wohlgemuth <curtw@google.com>, linux-ext4@vger.kernel.org
Subject: Re: ext4: Can we talk about bforget() and metadata blocks
Date: Thu, 10 Sep 2009 14:58:26 -0400 [thread overview]
Message-ID: <20090910185826.GC23700@mit.edu> (raw)
In-Reply-To: <20090910162435.GA5321@skywalker.linux.vnet.ibm.com>
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)) {
next prev parent reply other threads:[~2009-09-10 18:58 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 [this message]
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
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=20090910185826.GC23700@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=curtw@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).