Re: [RFC PATCH 2/3] vfs: Add open by file handle support

["J. Bruce Fields" <bfields@fieldses.org>]

On Sun, Feb 21, 2010 at 11:42:45AM -0700, Andreas Dilger wrote:
> Yes, we looked at this in the past for Lustre as well, and while we had 
> proposed a patch for the NFSd code to extract the FSID from the  
> filesystem, it was turned down because "setting the FSID via a userspace 
> file is the right thing to do".  I have enough on my plate not to wage an 
> uphill battle for this.
>
> I don't necessarily agree, because that means administering yet another 
> config parameter outside the filesystem on all of the servers.  I don't 
> mind allowing userspace to override the fs UUID-based FSID, but why not 
> let this be used by default instead of the devno (which is increasingly 
> dynamic these days).
>
> Maybe with more clustered filesystems in the kernel these days this idea 
> can gain more traction.

I agree that a cluster filesystem shouldn't need fsid= set right across
all servers.

But doesn't the libblkid uuid stuff as it's now implemented give you
what you need?

>> I haven't started writing any code to do this, but I have looked
>> at the current NFS FH code and it seems like it should be reasonable
>> to add a new set of methods to allow another FS specific field.
>
> First would be a method to extract the FSID/UUID from the filesystem.   
> That is immediately useful for even local configs.
>
>> The hardest part seems to be holding the size down to the old NFS v2
>> protocol limits.
>
> Would it not be possible to encode the FSID/UUID only into NFSv3/v4  
> handles, and leave the NFSv2 handles without this information?  I  
> imagine the usage of NFSv2 is growing ever smaller, and there isn't a  
> requirement to add this extra field there.

Yeah, I don't think NFSv2 support should be a high priority for new
features.

--b.