From: Christoph Hellwig <hch@infradead.org>
To: Ben Myers <bpm@sgi.com>
Cc: linux-nfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [RFC PATCH 0/4] wsync export option
Date: Thu, 4 Feb 2010 10:30:06 -0500 [thread overview]
Message-ID: <20100204153006.GC22014@infradead.org> (raw)
In-Reply-To: <20100203233755.17677.96582.stgit@case>
On Wed, Feb 03, 2010 at 05:44:24PM -0600, Ben Myers wrote:
> The following series is adds a 'wsync' export option to nfsd. It is intended
> to be used on XFS with the wsync mount option. When you already have a
> synchronous log there is no need to sync metadata separately.
You don't need the xfs wsync option, as the existing write_inode
calls or your new fsync calls are doing the same as the wsync mount
option, just from a higher layer. The wsync option causes the log
to be synchronously forced up to the log sequence number of the commit
for the metadata operation, that is make all the operations affected
by it synchronous. That's exactly what we'll do using fsync (actually
right now we force the whole log, but I have a patch to optimize it
to only force nuntil the last commit lsn), and approqimately the
same as we do using write_inode, just a lot less efficiently.
> This is barely tested, YMMV, I could have this all wrong, etc, etc. Here are
> some very unscientific measurements taken over gigabit ethernet.
>
> # time tar -xvf /mnt2/quilt-0.47.tar > /dev/null
>
> No XFS wsync, no NFS wsync:
> 0m13.177s 0m13.301s 0m13.528s
>
> XFS wsync set, no NFS wsync:
> 0m13.019s 0m13.232s 0m13.094s
>
> XFS wsync set, NFS wsync set:
> 0m8.361s 0m8.400s 0m8.301s
>
> Curious to hear if this is a reasonable thing to do. Suggestions welcome.
I think it's reasonable. What might be even better it to have an
export operation call out into the filesystem so that we can force wsync
and not let nfsd deal with it at all. There is a fair chance that the
filesystem can do the sync more efficiently.
And btw, not directly related to your patch, but getting rid of this
write_inode call defintively makes the usage of ->write_inode more
regular. From generic code we mostly use it for full inode writeback
in writeback_single_inode, and one other special case in
generic_detach_inode if a filesystem is unmounting. Only having
writeback_single_inode and fs code use it will make this call much
more predictable for the filesystem.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next parent reply other threads:[~2010-02-04 15:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100203233755.17677.96582.stgit@case>
2010-02-04 15:30 ` Christoph Hellwig [this message]
2010-02-04 18:15 ` [RFC PATCH 0/4] wsync export option bpm
2010-02-04 18:39 ` 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=20100204153006.GC22014@infradead.org \
--to=hch@infradead.org \
--cc=bpm@sgi.com \
--cc=linux-nfs@vger.kernel.org \
--cc=xfs@oss.sgi.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