On Sat, Aug 22, 2009 at 12:38:20AM +0530, Pramod Batni wrote: > Russ Weeks wrote: > >something that definitely points to a problem with fop_fid. The > >trimmed trace looks like this: > > > >CPU FUNCTION > > 0 -> exportfs > > 0 -> lookupname > >[a bunch of stuff here] > > 0 <- lookupname > > 0 -> fop_access > > 0 -> crgetmapped > > 0 <- crgetmapped > > 0 -> fuse_access > >[a bunch of FUSE-related stuff here] > > 0 <- fuse_access > > 0 <- fop_access > > 0 -> vn_mountedvfs > > 0 <- vn_mountedvfs > > 0 -> fop_fid > > 0 -> fs_nosys > > 0 <- fs_nosys > > 0 <- fop_fid > >[then exportfs returns with 89, ENOSYS]
Blammo: fop_fid() calling fs_nosys() means FUSE doesn't support the VOP_FID() operation. There's a corresponding operation too, VFS_VGET(). > >I think I'll try hacking something together in the FUSE kernel module > >to return a value for the VOP_FID call. I guess the best solution > >would be to expose that call to userspace through /dev/fuse (or would > >that break compatibility with existing Linux+BSD fuse implementations? > >Is that important?) but a quick kernel hack will get me started. The VOP_FID() operation can't just return anything. It has to return something akin to an inode number such that VFS_VGET() called with a FID output by VOP_FID() will return the same vnode whose FID you got from VOP_FID(). Technically you can do this entirely at the FUSE layer, but the resulting FIDs will necessarily be "volatile", which means that they can go stale even though the original file is still around. (Technically NFSv4 servers should be able to do the same thing and advertise as much to the clients by serving what are called "volatile filehandles". The Solaris NFSv4 fileserver does not have this feature. Implementing it at the FUSE layer should be OK, though with stale FH failure mode, and letting the NFSv4 server know that the FIDs are volatile via a VOP_PATHCONF(), say, would allow the Solaris NFSv4 server to advertise the FH volatility to clients.) Ideally FUSE would do that only for filesystems that don't have a notion of "inode number", e.g., FAT. For all other filesystems the FUSE plugins should support VOP_FID()/VFS_VGET(). > >Can anybody explain to me why I don't see the call to fop_access or > >fop_fid when I look at the exportfs function in nfs_export.c? I > >expect I'm missing something really basic. fop_*() are called by VOP_*(): > Each filesystem implements the VOP_* interface functions and the kernel > code calls into the filesystem code > via these VOP interfaces. Nico --
