How to fill in the fsid for file systems?

[Rick Macklem]

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.
mountd uses getfh(2) to acquire a file handle at mount time for a client. So, for
NFSv3 it does use getfh(2) to acquire the "root" file handle for the mount.
(Technically, it's the Mount protocol, but since that is required for NFSv3 mounting,
 you might as well call it NFS and this one needs to be an NFS usable file handle.)
>>
>> 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).
Good point. SInce the NLM isn't NFS I tend to forget about it.

rick