linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Nick Piggin <npiggin@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 10/11] hfsplus: optimize fsync
Date: Thu, 18 Nov 2010 14:50:47 +0100	[thread overview]
Message-ID: <20101118135047.GA14669@lst.de> (raw)
In-Reply-To: <AANLkTikQ7z8x-WnAT8jsq61Nb-91T-YN6Zfdqz=FXXWM@mail.gmail.com>

On Thu, Nov 18, 2010 at 05:40:44PM +1100, Nick Piggin wrote:
> Does this guy ever get cleared in the synchronous path? Or only in writeback?
> I couldn't see where it gets cleared from direct writeout, I wonder if we should
> import the pagecache tagged dirty check from writeback to keep this in sync
> better? (anyway, separate issue)
> 
> Anyway, what if writeback noticed pagecache was cleaned at this point, and then
> clears I_DIRTY bits from inode before you test it above? Won't that leave your
> metadata not on disk?

What do you mean with direct writeout?  For hfsplus we always write
the inode through writeback_single_inode, either from the writeback
threads, or through sync_inode_metadata (or previously write_inode_now)
in fsync.  Both of these clear I_DIRTY.  But one thing I noticed when
reading through the above is that I_DIRTY is overkill here - we only
care about metadata, as the pagecache is handled by vfs_fsync. Just
checking I_DIRTY_SYNC (and eventually I_DIRTY_DATASYNC when adding
support for an optimized fdatasync) would be enough.  The code is
take from generic_file_fsync, which is used or copied by a lot of
filesystems, so it looks like no one really cared about the possibly
superflous I_DIRTY_PAGES checking so far.

> > @@ -590,6 +602,8 @@ int hfsplus_cat_write_inode(struct inode
> > ? ? ? ? ? ? ? ?hfs_bnode_write(fd.bnode, &entry, fd.entryoffset,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sizeof(struct hfsplus_cat_file));
> > ? ? ? ?}
> > +
> > + ? ? ? set_bit(HFSPLUS_I_CAT_DIRTY, &HFSPLUS_I(inode)->flags);
> > ?out:
> > ? ? ? ?hfs_find_exit(&fd);
> > ? ? ? ?return 0;
> 
> So your I_CAT_DIRTY will be set, but not I_DIRTY, AFAIKS.

This in ->write_inode which is called to clear I_DIRTY (well,
(I_DIRTY_SYNC|I_DIRTY_DATASYNC).  But given the way how hfsplus stores
it's equivalents of inode and dirent in the catalog btree it means
dirtying the btree.  If ->write_inode is called by fsync that gets
picked up by the fsync code checking for I_CAT_DIRTY, if it's for
sync or during umount it's caught by the unconditionaly flush of it
in hfsplus_sync_fs.  The write_inode during nfs exporting is not handled
yet, but adding a commit_metadata operation is on my todo list.

> > @@ -530,4 +532,5 @@ out:
> > ? ? ? ?hip->fs_blocks = (inode->i_size + sb->s_blocksize - 1) >> sb->s_blocksize_bits;
> > ? ? ? ?inode_set_bytes(inode, hip->fs_blocks << sb->s_blocksize_bits);
> > ? ? ? ?mark_inode_dirty(inode);
> > + ? ? ? set_bit(HFSPLUS_I_ALLOC_DIRTY, &HFSPLUS_I(inode)->flags);
> 
> If you mark these sub-parts of the inode dirty after marking the inode
> dirty, and no
> locking, then AFAIKS you get no guarantee they will be noticed at the point that
> I_DIRTY bits are cleared.

Yes, it should be before.  I had fixed that up in the other places but
missed this one.  Thanks for the review!

  reply	other threads:[~2010-11-18 13:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17 22:21 hfsplus patch review Christoph Hellwig
2010-11-17 22:21 ` [PATCH 1/11] hfsplus: silence a few debug printks Christoph Hellwig
2010-11-17 22:21 ` [PATCH 2/11] hfsplus: always use hfsplus_sync_fs to write the volume header Christoph Hellwig
2010-11-17 22:22 ` [PATCH 3/11] hfsplus: use raw bio access for the volume headers Christoph Hellwig
2010-11-17 22:22 ` [PATCH 4/11] hfsplus: use raw bio access for partition tables Christoph Hellwig
2010-11-17 22:22 ` [PATCH 5/11] hfsplus: make sure sync writes out all metadata Christoph Hellwig
2010-11-17 22:22 ` [PATCH 6/11] hfsplus: avoid useless work in hfsplus_sync_fs Christoph Hellwig
2010-11-17 22:22 ` [PATCH 7/11] hfsplus: simplify fsync Christoph Hellwig
2010-11-17 22:22 ` [PATCH 8/11] hfsplus: write up fsync for directories Christoph Hellwig
2010-11-17 22:23 ` [PATCH 9/11] hfsplus: split up inode flags Christoph Hellwig
2010-11-17 22:23 ` [PATCH 10/11] hfsplus: optimize fsync Christoph Hellwig
2010-11-18  6:40   ` Nick Piggin
2010-11-18 13:50     ` Christoph Hellwig [this message]
2010-11-18 14:13       ` Nick Piggin
2010-11-18 14:16         ` Christoph Hellwig
2010-11-22 13:03           ` Nick Piggin
2010-11-22 13:18             ` Nick Piggin
2010-11-22 13:29               ` Christoph Hellwig
2010-11-22 11:35     ` [PATCH v2] " Christoph Hellwig
2010-11-17 22:23 ` [PATCH 11/11] hfsplus: flush disk caches in sync and fsync Christoph Hellwig

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=20101118135047.GA14669@lst.de \
    --to=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=npiggin@gmail.com \
    /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).