Re: NFS and non-blkdev-backed FS?

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Sat, 2008-08-16 at 14:11 -0400, Christoph Hellwig wrote:
> On Fri, Aug 15, 2008 at 10:18:12AM -0400, Trond Myklebust wrote:
> > On Fri, 2008-08-15 at 14:59 +0100, David Woodhouse wrote:
> > > On Fri, 2008-08-15 at 11:55 +0300, Artem Bityutskiy wrote:
> > > > UBIFS (as e.g. XFS) has a 16-byte UUID in superblock which is
> > > > supposed to uniquely identify the file-system. I'd like to use
> > > > this UUID as NFS FSID instead, however, I failed to find how
> > > > to do this. Any hints how could I do this?
> > > 
> > > By adding a 'get_fsid()' method to the export_ops structure...
> > > 
> > 
> > If the uuid can be found by libuuid, then it will automatically be used
> > as the default identifier by rpc.mount (man 5 exports). There should be
> > no need for a new export_ops method.
> 
> We'll need it anyway, for exports not starting at the root of the
> volume, and we'll need a method to be called when exporting a filesystem
> to reject it if the filehandle couldn't fit into the space available
> for the given nfs protocol version.

So far we've been using the pair (fsid:fileid) to label the export
inode. Why does using a UUID as the fsid change that?

As for the problem of dealing with a uuid-based filehandle not fitting
into the NFSv2 maximum of 32-bytes, why is that any different from the
general problem of defining alternative globally unique identifiers, and
why do we now think we can do that better in the kernel rather than
relying on the previous strategy of defining such identifiers in
userland?