Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts

[David Howells]

Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote:

> Why not just use the mount path as the default uniquifier?

Because:

 (1) Which mount path?  You're now constructing the mount tree in its own
     private namespace.

 (2) Due to the new VFS-pathwalk-based mount, the uniquifier is applied to the
     root mount only, and if modified to inherit, would be applied to every
     automount subordinate to that, rather than just the actual subject of the
     mount.

 (3) Due to the new VFS-pathwalk-based mount and the private namespace, the
     default uniquifier for all instances of any particular mount is always
     the same.

 (4) If we work around some how the mounts now getting their mount path from
     the private namespace, there are still real namespaces, chroots and
     root-pivots to contend with.

> > +	target->options = source->options;
> 
> BTW: Why does fscache require a private flag field?

I thought it best to avoid touching nfs_server::flags as that is at least
partially visible to userspace.

> > +	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };
> 
> Rather than wasting all this space on the stack, how about just changing
> the second argument of nfs_fscache_get_super_cookie()? You only use the
> pointer to data->fscache_uniq.

Yeah, that's probably wise.

Actually, I don't really want to get this data via mount at all (as there are
automounts to locally configure for caching).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/