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

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

On Sun, Feb 28, 2010 at 10:55:34AM -0700, Andreas Dilger wrote:
> On 2010-02-26, at 12:21, J. Bruce Fields wrote:
>> 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 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'm not sure what you mean?

With recent mountd and kernel, knfsd generates filehandles using a uuid
passed down from mountd, which mountd gets from libblkid.

> On the clients (where the NFS servers are  
> running) there are no block devices, so I don't think libblkid is  
> relevant.

Oh, OK.  (Though for a shared-disk cluster-filesystem it should be
enough, yes?)

> Lustre itself already can provide a UUID/fsid that is the  
> same on all clients, but there is no way to pass this to NFSd.
>
> If there is interest to revive this idea, I'll try to dig up the old  
> patches we had. I believe that they set a FS_NFS_FSID (or similarly  
> named) flag in the file_system_type, and possibly a method that  
> extracted this information for NFSd.

OK, sure, but if it's only of use to lustre than I don't see how to
justify a kernel patch.

Another option would be to provide an alternative to
nfs-utils/utils/mountd/cache.c's get_uuid() that can request the
filesystem's uuid (assuming you've got an easy way to get it from
userspace).  That might also save having to add yet another case to e.g.
fs/nfsd/nfsfh.c:set_version_and_fsid_type().

--b.