Re: Link performance over NFS degraded in RHEL5. -- was : Read/Write NFS I/O performance degraded by FLUSH_STABLE page flushing

Trond Myklebust
2009-06-04T21:49:05Z

Well, that's a good reason to get rid of those Solaris servers. :-)

Seriously, though, we do _not_ fix server bugs by changing the client.
If we had been doing something that was incorrect, or not recommended
by the NFS spec, then matters would be different...

Trond

On Jun 4, 2009, at 17:30, Brian R Cowan <brcowan@us.ibm.com> wrote:

> I'll have to see if/how this impacts the flush behavior. I don't
> THINK we
> are doing getattrs in the middle of the link, but the trace
> information
> kind of went astray when the VM's gor reverted to base OS.
>
> Also, your recommended workaround of setting no_wdelay only works if
> the
> NFS server is Linux, the option isn't available on Solaris or HP-UX.
> This
> limits it's usefulness in heterogenous environments. Solaris 10
> doesn't
> support async NFS exports, and we've already discussed how the small-
> write
> optimization overrides write behavior on async mounts.
>
> =================================================================
> Brian Cowan
> Advisory Software Engineer
> ClearCase Customer Advocacy Group (CAG)
> Rational Software
> IBM Software Group
> 81 Hartwell Ave
> Lexington, MA
>
> Phone: 1.781.372.3580
> Web: http://www.ibm.com/software/rational/support/
>
>
> Please be sure to update your PMR using ESR at
> http://www-306.ibm.com/software/support/probsub.html or cc all
> correspondence to sw_support@us.ibm.com to be sure your PMR is
> updated in
> case I am not available.
>
>
>
> From:
> Trond Myklebust <trond.myklebust@fys.uio.no>
> To:
> Brian R Cowan/Cupertino/IBM@IBMUS
> Cc:
> Carlos Carvalho <carlos@fisica.ufpr.br>, linux-nfs@vger.kernel.org,
> linux-nfs-owner@vger.kernel.org
> Date:
> 06/04/2009 04:57 PM
> Subject:
> Re: Link performance over NFS degraded in RHEL5. -- was : Read/Write
> NFS
> I/O performance degraded by FLUSH_STABLE page flushing
>
>
>
> On Thu, 2009-06-04 at 16:43 -0400, Brian R Cowan wrote:
>> What I'm trying to understand is why RHEL 4 is not flushing anywhere
> near
>> as often. Either RHEL4 erred on the side of not writing, and RHEL5 is
>> erring on the opposite side, or RHEL5 is doing unnecessary flushes...
> I've
>> seen that 2.6.29 flushes less than the Red hat 2.6.18-derived
>> kernels,
> but
>> it still flushes a lot more than RHEL 4 does.
>
> Most of that increase is probably mainly due to the changes to the way
> stat() works. More precisely, it would be due to this patch:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=70b9ecbdb9c5fdc731f8780bffd45d9519020c4a
>
>
> which went into Linux 2.6.16 in order to fix a posix compatibility
> issue.
>
> Trond
>
>
>