linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	linux-ext4@vger.kernel.org
Subject: Re: fsync on ext[34] working only by an accident
Date: Thu, 10 Sep 2009 12:52:01 -0400	[thread overview]
Message-ID: <20090910165201.GA23700@mit.edu> (raw)
In-Reply-To: <20090910140636.GJ607@duck.suse.cz>

On Thu, Sep 10, 2009 at 04:06:36PM +0200, Jan Kara wrote:
> > In fact, I think the problem is worse than Jan is pointing out,
> > because it's not enough that vfs_fq_alloc_space() is calling
> > mark_inode_dirty(), since that only sets I_DIRTY_SYNC.  When we touch
> > i_size or i_block[], we need to make sure that I_DIRTY_DATASYNC is
> > set, so that fdatasync() will force a commit.
>   Actually no. mark_inode_dirty() dirties inode with I_DIRTY ==
> (I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_PAGES) so it happens to work.
> The fact that quota *could* dirty the inode with I_DIRTY_SYNC only
> is right but that's a separate issue.

Oops, you're right.  I mixed up I_DIRTY and I_DIRTY_SYNC.  Hmm, what's
actually a bit surprising is that we don't have a
mark_inode_dirty_datasync() which only sets I_DIRTY_DATASYNC.

And shouldn't quota be dirtying the inode using I_DIRTY_DATASYNC only?
After, all the reason why we need to do this is because it's messing
with i_size, right?

>   Thinking about it, it won't work so easily. The problem is that when
> pdflush decides to write the inode, it unconditionally clears dirty flags.
> We could redirty the inode in write_inode() but that's IMHO too ugly to
> bear it.

Hmm, yes.  I wonder if this is something we should change, and make it
be the responsibility of the filesystem's write_inode method function
to clear I_DIRTY_SYNC and I_DIRTY_DATASYNC flags.  That would allow
the file system to refuse to clean the inode for whatever reason the
file system saw fit.  That would require sweeping through all of the
file systems, but it might be useful for more file systems other than
ext3/ext4.

The problem is it's a little late, given that 2.6.31 has already been
released, to try to get consensus on that way of doing things.
Tracking the TID is probably the best short-term way of handling this
problem, although it means bloating the in-core inode by another four
bytes, which is a bit of a shame.

       	     				- Ted

  reply	other threads:[~2009-09-10 16:52 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
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 [this message]
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=20090910165201.GA23700@mit.edu \
    --to=tytso@mit.edu \
    --cc=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 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).