How to fill in the fsid for file systems?

[Andriy Gapon]

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

-- 
Andriy Gapon