On 08/10/12 12:47, VDR User wrote: > On Mon, Oct 8, 2012 at 3:58 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>> Per Aníbal Salazar, I'm sending this to the nfs mailing list.. >>> >>> ========== >>> >>> Hi. I would like to know who I can talk to about having the rpcbind's >>> timeout value settable on the command line by the user. In many cases >>> the timeout is too long, requiring hackish solutions. It would be >>> best, and makes sense, that the user should be able to set the timeout >>> to something other than the default value if he chooses. If you could >>> direct me to the right person to talk to about it, I'd appreciate it. >> >> What timeout are you referring to? The one given to poll()? > > Hi. I guess so but not really sure. I'm talking about the timeout that > happens when rpcbind is waiting for a response. Sounds like poll() > could be it. We have an nfs server on .100 and the response happens > immediately. > > $ rpcinfo -t 192.168.1.100 nfs > program 100003 version 2 ready and waiting > program 100003 version 3 ready and waiting > program 100003 version 4 ready and waiting > > but there's no server on say .101 so if we run the same command on > that ip, the timeout takes a very long time. It's this timeout that > should be user-definable on the command line in my opinion. Any > thoughts about it? Hmm... I'm guess that is the 7min tcp connect time out cause by the -t option... Try using -u instead of -t... Basically using UDP instead of TCP... In general I would never recommend that but in this particular case it might help... steved. -- 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
