On Tue, 2012-03-13 at 09:23 -0400, Nikolaus Rath wrote:
> "Myklebust, Trond" <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@xxxxxxxxxxxxxxxx> writes:
> >> > Oh, so the clientaddr detection takes place only once at the beginning,
> >> > and is not repeated if the mount attempts are repeated?
> >> >
> >> > This would explain what's happening. The VPN is not yet up when the
> >> > system first attempts to mount the share.
> >> >
> >> > Is there a rationale behind this? It seems to me that if the mount is
> >> > retried, it would be reasonable to expect that the clientaddr detection
> >> > is retried as well.
> >>
> >> There's no reason I can recall requiring that this is done only once, other than it's the simplest implementation for mount.nfs. Historically, NFS is deployed on systems with static network configurations that are supposed to be set up before the NFS utilities come into play. As Bruce suggested, perhaps this design assumption needs to be revisited.
> >>
> >> I suppose I should file a bug.
> >
> > Consider the whole 'bg' option to be a bug at this point.
> >
> > Now that we have working autofs support for direct mounts, there is no
> > reason to keep the 'bg' mount option on life support any more.
>
> I'm not sure that this would be a solution. What happens if some
> program accesses the autofs mountpoint before the VPN is up? Wouldn't
> autofs try to mount the NFS share right away and thus with a broken
> clientaddr?
Unlike the 'bg' case, the mount should fail immediately, and your
program gets an ENOENT error. This is exactly what should happen if a
program tries to access a filesystem that isn't available.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
