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!
next prev parent 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).