"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? Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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
