On Thu, Aug 16, 2018 at 2:56 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > David Howells <dhowells@xxxxxxxxxx> writes: > > > Having just re-ported NFS on top of the new mount API stuff, I find that I > > don't really like the idea of superblocks being separated by communication > > parameters - especially when it might seem reasonable to be able to adjust > > those parameters. > > > > Does it make sense to abstract out the remote peer and allow (a) that to be > > configured separately from any superblocks using it and (b) that to be used to > > create superblocks? <snip> > At least for devpts we always create a new filesystem instance every > time mount(2) is called. NFS seems to have the option to create a new > filesystem instance every time mount(2) is called as well, (even if the > filesystem parameters are the same). And depending on the case I can > see the attraction for other filesystems as well. > > So I don't think we can completely abandon the option for filesystems > to always create a new filesystem instance when mount(8) is called. In cifs we attempt to match new mounts to existing tree connections (instances of connections to a \\server\share) from other mount(s) based first on whether security settings match (e.g. are both Kerberos) and then on whether encryption is on/off and whether this is a snapshot mount (smb3 previous versions feature). If neither is mounted with a snaphsot and the encryption settings match then we will use the same tree id to talk with the server as the other mounts use. Interesting idea to allow mount to force a new tree id. What was the NFS mount option you were talking about? Looking at the nfs man page the only one that looked similar was "nosharecache" > I most definitely support thinking this through and figuring out how it > best make sense for the new filesystem API to create new filesystem > instances or fail to create new filesystems instances. Yes - it is an interesting question. -- Thanks, Steve
