On Tue, Feb 06, 2007 at 10:37:37AM +0000, Christoph Hellwig wrote: > On Tue, Feb 06, 2007 at 09:26:14PM +1100, Neil Brown wrote: > > What would be the benefit of having private non-visible vfsmounts? > > Sounds like a recipe for confusion? > > > > It is possible that mountd might start doing bind-mounts to create the > > 'pseudo filesystem' thing for NFSv4, but they would be very visible > > (under /var/lib/nfs/v4root or something). > > So having it's own vfsmount might make sense, but I don't get > > 'non-visible'. > It would allow creating an exported tree without interferance with > the local visible tree. Note that the local visible tree isn't > global anymore either, and this allows to adjust what's exported > through nfsd throug a specific interface instead of needing to > get into nfsd namespace through some way. What would this interface look like? Would it be a user<->kernel interface, or a user<->mountd interface? Tentatively what I was thinking of was having mountd fork off its own namespace, use /etc/exports to construct a mount tree there, then pass that mount tree down to the kernel using the existing exports cache channel. Name resolution in svc_export_parse should be done in mountd's namespace, so I think this works. > Think of listing the actually exported devices in /etc/exports instead > of the indirection through fstab aswell. Hm. We'd have to add mount options to /etc/exports too if we were going to do that, right? --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
