On 6/5/2009 9:28 AM, 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?
I'm not 100% clear on what you mean by removing it. Since it's
a "no_" option, removing it means that "wdelay" becomes the
default? That would certainly cause a regression for many.
I think the big problem with tweaking the default in nfs_utils
is that there's little guarantee of the kernel behavior that
would result. Older kernels, NFSv2 mounts, etc will behave completely
differently from new ones, NFSv3, modified clients, etc. So
touching this option is quite risky, IMO, even though it's a
crock.
Tom.
--
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
