From: Christoph Hellwig <hch@infradead.org>
To: bpm@sgi.com
Cc: xfs@oss.sgi.com
Subject: Re: nfs performance delta between filesystems
Date: Mon, 25 Jan 2010 10:04:10 -0500 [thread overview]
Message-ID: <20100125150410.GA25699@infradead.org> (raw)
In-Reply-To: <20100122183848.GB28561@sgi.com>
On Fri, Jan 22, 2010 at 12:38:48PM -0600, bpm@sgi.com wrote:
> Hey Emmanuel,
>
> I did some research on this in April last year on an old, old kernel.
> One of the codepaths I flagged:
>
> nfsd_create
> write_inode_now
> __sync_single_inode
> write_inode
> xfs_fs_write_inode
> xfs_inode_flush
> xfs_iflush
>
> There were small gains to be had by reordering the sync of the parent and
> child syncs where the two inodes were in the same cluster. The larger
> problem seemed to be that we're not treating the log as stable storage.
> By calling write_inode_now we've written the changes to the log first
> and then gone and also written them out to the inode.
>
> nfsd_create, nfsd_link, and nfsd_setattr all do this (or do in the old
> kernel I'm looking at). I have a patchset that changes
> this to an fsync so we force the log and call it good. I'll be happy to
> dust it off if someone hasn't already addressed this situation.
Dave and I had had some discussion about this when going through his
inode writeback changes. Changing to ->fsync might indeed be the
easiest option, but on the other hand I'm really trying to get rid of
the special case of ->fsync without a file argument in the VFS as it
complicates stackable filesystem layers and also creates a rather
annoying and under/un documented assumtion that filesystem that need
the file pointer can't be NFS exported. One option if we want to
keep these semantics is to add a new export operation just for
synchronizations things in NFS.
But given that the current use case in NFS is to pair one write_inode
call with one actual VFS operation it might be better to just
automatically turn on the wsync mount option in XFS, we'd need a hook
from NFSD into the filesystem to implement this, but I've been looking
into adding this anyway to allow for checking other paramters like the
file handle size against filesystem limitations. Any chance you
could run your tests against a wsync filesystem?
But all this affects metadata performance, and only for sync exports,
while the OP does a simple dd which is streaming data I/O and uses the
(extremly unsafe) async export operation that disables the write_inode
calls.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-01-25 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 17:54 nfs performance delta between filesystems Emmanuel Florac
2010-01-22 18:38 ` bpm
2010-01-22 20:46 ` Emmanuel Florac
2010-01-23 12:30 ` Dave Chinner
2010-01-25 15:04 ` Christoph Hellwig [this message]
2010-01-25 20:28 ` bpm
2010-01-25 20:40 ` 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=20100125150410.GA25699@infradead.org \
--to=hch@infradead.org \
--cc=bpm@sgi.com \
--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