Re: bug with multiple mounts of filesystems in 2.6

[Trond Myklebust <trond.myklebust@fys.uio.no>]

På må , 26/07/2004 klokka 20:56, skreiv Mike Waychison:

> As an example where sharing the super_block is wrong (albeit probably
> just an oversight) is that the protocols (udp vs tcp) are not compared
> in nfs_compare_super.  You could argue that the client fhandles should
> be different though, I'm not sure..

Not an oversight. It's just that we don't really have a model for
trunking a single cache over several different RPC connections.
Basically, it all boils down to the problem that inodes and dentries
have no idea of which namespace you used to access them, and hence even
if you did have space in the vfsmount in which to store an rpc_client
struct and perhaps rsize/wsize ... you still have a reconstruction job
to do.

> Another 'bind mount extension' that would be nice to change at the
> vfsmount level may be w/rsize, but that is probably a very intrusive
> change for nfs and probably not possible.  Thoughts?

The "struct nfs_open_context" I introduce in the latest NFS4_ALL patches
could probably be modified to include vfsmount information.

My question is why do people need to do this? What problems does it
solve?
Normally, rsize/wsize are per-server parameters. Their optimal value
depends above all upon the quality of the network link between client
and server. Ditto for the choice of UDP vs TCP: why would you want to
choose to use both options against a given server?

> [1] - I haven't tested mounting nfs ro, and then mounting nfs rw using
> the bind extensions.  Does nfs make any assumptions about the mount
> being ro?

Nope, however the VFS support for this is missing. That was part of what
Herbert was doing in his patches.

Cheers,
  Trond