[Top] [All Lists]

Re: nfs performance delta between filesystems

To: bpm@xxxxxxx
Subject: Re: nfs performance delta between filesystems
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 25 Jan 2010 15:40:21 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20100125202839.GA28087@xxxxxxx>
References: <20100122185419.63ae6430@xxxxxxxxxxxxxxxxxxxx> <20100122183848.GB28561@xxxxxxx> <20100125150410.GA25699@xxxxxxxxxxxxx> <20100125202839.GA28087@xxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
On Mon, Jan 25, 2010 at 02:28:39PM -0600, bpm@xxxxxxx 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?

<Prev in Thread] Current Thread [Next in Thread>