On Fri, 15 Oct 2010 09:11:55 -0400 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > >>> To summarize: instead of relying on /etc/mtab, also use an NFS-specific > >>> place to record the same information. umount.nfs can use that > >>> instead of /etc/mtab. And by the way, we don't touch this information > >>> during a remount... heh. That guarantees that we preserve existing > >>> good behaviors of umount.nfs, continue to update /etc/mtab as documented, > >>> until maybe it goes away, but eliminate our functional dependence on it. > >>> > >> If the info in /etc/mntab is not updated on remounts, then what is > >> the issue we are talking about? Just curious, will the info in /proc/mounts > >> be updated on remounts? > > > > /etc/mtab would still be updated on remounts, and would still have the > > bug where "remount" would wipe the options. But we would no longer depend > > on that destroyed information to perform the umount reliably. > The remount would wipe out the *original* options, basically overriding > them with the updated options... As long as we have a mechanism to > retry the UMNT if the first call fails, I don't see this a being a > problem... > FWIW, I think the only info we really need to worry about preserving in mtab is the "user=" and "users" options. Without those, you can have user mountable filesystems that may become un-unmountable by those users. This is true whether umount.nfs stays or not. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
