[The fuse-discuss list rejects non-subscriber posts. That is really obnoxious -- I'm not going to subscribe just for these posts!]
On Fri, Aug 21, 2009 at 09:37:42PM +0200, Roland Mainz wrote: > > Aghrrll... I start to rememeber this issue from my "podfuk"/CODA > filesystem work. Technically the userland parts (e.g. the API library > which calls the kernel module, not the kernel module itself) of FUSE > needs to implement this using file on permanent storage to write down > the FID<--->FUSE_FILE relationships. This is harmless and easy to > implement but requires some thinking first to make sure this really > works across reboots... NFSv4 supports volatile FHs, in which case FIDs constructed on the fly by FUSE (or the NFS server, or the FUSE plugin) need not be persistent. When a non-volatile FH goes stale NFSv4 clients simply return ESTALE. When a volatile FH goes stale NFSv4 clients are supposed to try to recover by re-doing the LOOKUPs and OPENs of the path components that led to the now-stale volatile FH. (Yes, that means that renames/rmdir/ unlinks of any of those components will cause stale volatile FH recovery to fail.) > > in order to allow the NFS server to construct proper file handles. > > (see vfs.h, struct fid_t) > > Is there a flag in the VFS API which indicates that the inodes are > volatile ? Dunno. But I suspect (I asserted before, but I might have been wrong) that the Solaris NFSv4 server does not support volatile FHs. It really wouldn't be hard to add a bit of code to call VOP_PATHCONF() on mount points to see if they always return volatile FHs, and then act accordingly. Nico --
