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

J. Bruce Fields
2009-06-05T16:05:45Z

On Fri, Jun 05, 2009 at 09:57:19AM -0400, Steve Dickson wrote:
>
>
> Trond Myklebust wrote:
> > On Fri, 2009-06-05 at 09:30 -0400, Steve Dickson wrote:
> >> Tom Talpey wrote:
> >>> On 6/5/2009 7:35 AM, Steve Dickson wrote:
> >>>> Brian R Cowan wrote:
> >>>>> Trond Myklebust<trond.myklebust@fys.uio.no> wrote on 06/04/2009
> >>>>> 02:04:58
> >>>>> PM:
> >>>>>
> >>>>>> Did you try turning off write gathering on the server (i.e. add the
> >>>>>> 'no_wdelay' export option)? As I said earlier, that forces a delay of
> >>>>>> 10ms per RPC call, which might explain the FILE_SYNC slowness.
> >>>>> Just tried it, this seems to be a very useful workaround as well. The
> >>>>> FILE_SYNC write calls come back in about the same amount of time as the
> >>>>> write+commit pairs... Speeds up building regardless of the network
> >>>>> filesystem (ClearCase MVFS or straight NFS).
> >>>> Does anybody had the history as to why 'no_wdelay' is an
> >>>> export default?
> >>> Because "wdelay" is a complete crock?
> >>>
> >>> Adding 10ms to every write RPC only helps if there's a steady
> >>> single-file stream arriving at the server. In most other workloads
> >>> it only slows things down.
> >>>
> >>> The better solution is to continue tuning the clients to issue
> >>> writes in a more sequential and less all-or-nothing fashion.
> >>> There are plenty of other less crock-ful things to do in the
> >>> server, too.
> >> Ok... So do you think removing it as a default would cause
> >> any regressions?
> >
> > It might for NFSv2 clients, since they don't have the option of using
> > unstable writes. I'd therefore prefer a kernel solution that makes write
> > gathering an NFSv2 only feature.
> Sounds good to me! ;-)

Patch welcomed.--b.