How to fill in the fsid for file systems?

[Warner Losh]

On Fri, Nov 2, 2018 at 5:37 AM Konstantin Belousov <kostikbel at gmail.com>
wrote:

> On Fri, Nov 02, 2018 at 08:53:22AM +0200, Andriy Gapon wrote:
> > On 02/11/2018 08:45, Andriy Gapon wrote:
> > > On 02/11/2018 04:24, Rick Macklem wrote:
> > >> I have two comments. The first is related to the above and the second
> is a big
> > >> picture question related to doing this.
> > >>
> > >> Specifically w.r.t. the above. I probably rambled and didn't make
> what I was
> > >> trying to say clear, so I'll try again...
> > >> - getfh(2) returns a file handle that is used for NFS, but is also
> used for system
> > >>   calls (fhopen(2), fhstat(2) and fhstatfs(2)) that are not related
> to NFS.
> > >>   --> A file handle isn't really NFS specific, although NFS is the
> big user of it.
> > >> If the above is correct, then it seems that there should only be one
> kind of file handle.
> > >> --> Since the fsid is a key part of a file handle, one kind of file
> handle implies one
> > >>      kind of fsid.
> > >> I just think trying to create two kinds of fsid and two kinds of file
> handle would
> > >> make the code confusing and unnecessarily complex.
> > >
> > > As as far as I understand, VFS calls like, say, VOP_VPTOFH fill only
> the file ID
> > > portion of the file handle, fh_fid.  fh_fsid is left to a caller, so
> potentially
> > > we could already have a discrepancy there (but we don't).
> > >
> > > Also, I do not think that NFS uses getfh(2), but I could be wrong.  I
> think that
> > > NFS, being in kernel, directly uses VFS interfaces like the mentioned
> VOP_VPTOFH.
> > >
> > > I am not sure if getfh(2) has any requirement that its result should be
> > > compatible with anything NFS.  My impression is that it should only be
> usable
> > > for fhopen(2) and the like.  But I can be wrong again.
> > >
> > > So, if any of my assumptions is wrong, then you are right, of course,
> and I
> > > should withdraw my argument.
> > > Thanks!
> > >
> >
> > Looking through the actual code, it appears that rpc.lockd (and only
> it?) could
> > be mixing NFS and local file handles...  I suspect, but not sure, that
> lockd
> > could pass a file handle received "from NFS" to fhopen(2).
>
> I believe userspace nfs server implementations exist, and they have to use
> fhopen(2).
>

You are correct. NFS is the reason these interfaces exist because it has
historically (or at least initially) been implemented in userspace.

Warner