How to fill in the fsid for file systems?

Konstantin Belousov kostikbel at gmail.com
Fri Nov 2 11:36:22 UTC 2018


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).


More information about the freebsd-fs mailing list