On 11/10/12 11:02, VDR User wrote: > On Thu, Oct 11, 2012 at 6:23 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... >>> >>> Thanks for this suggestion. I tried with -u but the timeout still >>> takes at least 1 min. Is it not feasible to have a command line >>> timeout where users can set it to something appropriate for their >>> needs? For example, in our case we only need about 5 seconds at most. >> >> hmm... when I do a "rpcinfo -t <ip-address> nfs" to a machine that >> does not have a daemon listening I immediately get: >> rpcinfo: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused) program 100003 is not available >> >> So I not seeing here this hang is coming from... > > The computers on our network run a mixture of different OS'es so maybe > that is relevant. Regardless though it makes sense that we should be > able to tell rpcbind to abort if I hasn't received a response within X > seconds. That's much better than being forced to wait predefined > timeouts, or timeouts in other places. Or is it just me? I guess... but there are a lot of timeout one has to deal with... If its high on your priority, patches are always welcome... ;-) 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
