From: Christoph Hellwig <hch@infradead.org>
To: bpm@sgi.com
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: nfs performance delta between filesystems
Date: Mon, 25 Jan 2010 15:40:21 -0500 [thread overview]
Message-ID: <20100125204021.GA6191@infradead.org> (raw)
In-Reply-To: <20100125202839.GA28087@sgi.com>
On Mon, Jan 25, 2010 at 02:28:39PM -0600, bpm@sgi.com wrote:
> The original tests were done with the wsync mount option. I'm not
> really sure that it was necessary. Test case was "tar -xvf
> ImageMagick.tar". 'fdatasync' represents whether the export option
> controlling usage of write_inode_now vs fsync was set.
Ok. Btw, you need to call ->fsync with fdatasync = 0 for NFS as it
also wants to catch non-data changes to the inode. Doesn't matter
for XFS as we currently always force a full fsync, but I'm going to
change that soon.
> internal log, no wsync, no fdatasync
> 2m48.632s 2m59.676s 2m42.450s
>
> internal log, wsync, no fdatasync
> 3m1.320s 3m10.961s 2m53.560s
>
> internal log, wsync, fdatasync
> 1m40.191s 1m38.780s 1m35.758s
The wsync case always still includes either the ->fsync or write_inode
call, right? If we use wsync we shouldn't need either in theory as
the transactions already commit synchronously.
Anyway, given the massive improvements of ->fsync vs write_inode you
really should post that patch to the NFS list for discussion ASAP.
> > 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.
>
> Right. This might not apply to Emmanuel's problem. I've been wondering
> if a recent change to not hold the inode mutex over the sync helps in
> the streaming io case. Any idea?
It should help a bit. I'm not sure it can cause that much of a
difference for such a simple single-threaded workload. Emmanuel, is
there any chance you could try the latest 2.6.32-stable kernel or even
2.6.33-rc as those changes are included there?
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-01-25 20:39 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
2010-01-25 20:28 ` bpm
2010-01-25 20:40 ` Christoph Hellwig [this message]
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=20100125204021.GA6191@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