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@xxxxxxxxxx> 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. Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
