Re: NFS and non-blkdev-backed FS?

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Fri, 2008-08-15 at 10:18 -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...

That approach is painful -- it's simple enough to make the export work,
and it returns an appropriate root fh -- but then falls over immediately
when the client gives that fh back to us in an FSINFO request and
userspace mountd doesn't understand it. A hack to prepopulate the
svc_export_cache too 'fixes' it, but won't survive reboots.

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

The problem with libuuid is that it assumes that there's a block device,
and a 1:1 mapping between file system and block device. That often isn't
true.

However, there _is_ a f_fsid field in struct statfs64, which we could
happily use if libuuid fails.

See git.infradead.org/users/dwmw2/nfs-utils.git -- if the file system
fills in f_fsid, that should be all that's needed.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@xxxxxxxxx                              Intel Corporation



--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html