All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org
Subject: Re: fsync on ext[34] working only by an accident
Date: Thu, 10 Sep 2009 16:34:55 +0530	[thread overview]
Message-ID: <20090910110455.GA17531@skywalker.linux.vnet.ibm.com> (raw)
In-Reply-To: <20090910105216.GG607@duck.suse.cz>

On Thu, Sep 10, 2009 at 12:52:16PM +0200, Jan Kara wrote:
> On Thu 10-09-09 14:45:51, Aneesh Kumar K.V wrote:
> > On Thu, Sep 10, 2009 at 02:34:49PM +0530, Aneesh Kumar K.V wrote:
> > > On Thu, Sep 10, 2009 at 10:50:56AM +0200, Jan Kara wrote:
> > > >   Hi,
> > > > 
> > > > On Thu 10-09-09 12:16:05, Aneesh Kumar K.V wrote:
> > > > > On Tue, Sep 08, 2009 at 03:26:01PM +0200, Jan Kara wrote:
> > > > > >   When looking at how ext3/4 handles fsync, I've realized I don't
> > > > > > understand how writing out inode on fsync can work. The problem is that
> > > > > > ext3/4 mostly calls ext?_mark_inode_dirty() which actually does *not* dirty
> > > > > > the inode. It just copies the in-memory inode content to disk buffer.
> > > > > > So in particular the inode looks clean to VFS and our check in
> > > > > > ext?_sync_file() shouldn't trigger.
> > > > > >   The only obvious case when we call mark_inode_dirty() is from write_end
> > > > > > functions when we update i_size but that's clearly not enough. Now I did
> > > > > > some research why things seem to be actually working. The trick is that
> > > > > > when allocating block, we call vfs_dq_alloc_block() which calls
> > > > > > mark_inode_dirty(). But that's all what's keeping our fsync / writeout
> > > > > > logic from breaking!
> > > > > 
> > > > > ext4_handle_dirty_metadata should do mark_inode_dirty right ?
> > > > > __ext4_handle_dirty_metadata -> mark_buffer_dirty ->__set_page_dirty
> > > > > -> __mark_inode_dirty ->  list_move(&inode->i_list, &sb->s_dirty);
> > > >   ext4_handle_dirty_metadata() marks the buffer dirty only when we do not
> > > > have a journal (BTW, the inode that gets dirtied in the nojournal case
> > > > is the block-device one, not the one whose metadata we mark as dirty, so
> > > > it won't work there either - but Google guys are working on this I think).
> > > > With a journal the function just calls jbd2_journal_dirty_metadata which
> > > > does nothing with the inode.
> > > 
> > > When we don't have a journal handle we do that as a part of journal commit
> > > right ? __jbd2_journal_temp_unlink_buffer -> mark_buffer_dirty  
> > > 
> > > I guess fsync only requires the meta data update to be in journal ?
> > > 
> > 
> > Adding the file inode to the sb->s_dirty is done through block_write_end ?
> > Why do you mention above that it is not "clearly not enough" ?
>   Where? I don't see block_write_end() marking the inode dirty anywhere...
> It calls __block_commit_write() and that dirties only buffers, not the
> inode.


mark_buffer_dirty -> __set_page_dirty -> __mark_inode_dirty

-aneesh

  reply	other threads:[~2009-09-10 11:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08 13:26 fsync on ext[34] working only by an accident Jan Kara
2009-09-10  6:46 ` Aneesh Kumar K.V
2009-09-10  8:50   ` Jan Kara
2009-09-10  9:04     ` Aneesh Kumar K.V
2009-09-10  9:15       ` Jan Kara
2009-09-10  9:15       ` Aneesh Kumar K.V
2009-09-10 10:52         ` Jan Kara
2009-09-10 11:04           ` Aneesh Kumar K.V [this message]
2009-09-10 12:32             ` Jan Kara
2009-09-10 13:10             ` Theodore Tso
2009-09-10 14:06               ` Jan Kara
2009-09-10 16:52                 ` Theodore Tso
2009-09-14 16:00                   ` Jan Kara
2009-09-10 20:14                 ` Mingming
2009-09-14 15:25                   ` Jan Kara
2009-09-10 16:25               ` Aneesh Kumar K.V

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=20090910110455.GA17531@skywalker.linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=jack@suse.cz \
    --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.