"Frank Batschulat (Home)" wrote: > On Fri, 21 Aug 2009 21:09:58 +0200, Roland Mainz > <roland.mainz at nrubsig.org> wrote: > >> I bet when you dtrace the kernel exportfs syscall s entry exportfs() > >> you'll find that it fails > >> in treeclimb_export() because your underlaying FUSE file system does > >> not implement VOP_FID(). > > > > AFAIK this means the "fuse" kernel module needs to implement support for > > |VOP_FID()| and (optionally) allow FUSE userland drivers to implement > > this functionality... right ? > > precisely. fuse would need to implement VOP_FID and assemble reasonable > values > for FID
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... > 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 ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
