On Mon, 10 Mar 2014 10:18:16 +1100 NeilBrown <neilb@xxxxxxx> wrote: > On Sat, 8 Mar 2014 08:22:44 -0500 Steve Dickson <steved@xxxxxxxxxx> wrote: > > > Modern day kernel will no longer return all timeout > > errors instead the process spins endlessly in the kernel. > > This behavior will cause the foreground mount to hang, never > > allowing the mount to go into background. > > > > So this patch eliminates the foreground mount cause > > background mounts to go directly into background > > > > Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> > > Did NFS mounts *ever* time out (when 'soft' isn't given)? > > If so, there is probably a regression which maybe should be fixed. > > If not, then this has always been a bug since sting-options were introduced > and the kernel started doing the mountd filehandle lookup... > > So I'm probably OK with the patch but I wonder if there is more of a story > behind this that we should be sure we understand... > > Thanks, > NeilBrown Sorry, I really should read email in chronological order, shouldn't I :-) The foregoing discussion seemed to focus on NFSv4. Does NFSv3 behave the same way? A quick test suggests that it doesn't. mount -o bg,vers=3 server:/path /mnt backgrounds as it should after a few seconds. So I suspect this patch should be version dependent? However falling-back from v4 (which we leave entirely to the kernel) to v3 could be a bit awkward. I think that an NFSv4 mount really does need to timeout - whether that happens in the kernel or through the use of "alarm()" doesn't really bother me. But if it doesn't timeout, then it is violating the documentation and ignoring the retry= setting. NeilBrown
Attachment:
signature.asc
Description: PGP signature
