The combination of no MDCACHE and no OFD is not one we've ever tested. The vfs_state_entry was intended to support the OFD case, the no OFD case for VFS is handled it the global FD in the object handle itself. You should be able to use vfs_state_entry to hold a global FD, but I haven't tried it so I can't be sure.
Daniel On Wed, Sep 28, 2016 at 9:54 AM, Tushar Shinde <mtk.tus...@gmail.com> wrote: > Thanks Daniel for reply, > In case of no MDCACHE and no OFD, global file FD should be kept with > "struct vfs_state_entry" correct? > > > On Wed, Sep 28, 2016 at 7:20 PM, Daniel Gryniewicz <d...@redhat.com> wrote: >> It worked when I put it in, but I haven't tried it in quite a long >> time, so it may be broken at this point. You should be able to use >> the VFS state code if you're not using MDCACHE, since that's why it >> was written (to test cacheless). If you hit any issues with it, let >> me know. >> >> Daniel >> >> >> On Wed, Sep 28, 2016 at 9:32 AM, Tushar Shinde <mtk.tus...@gmail.com> wrote: >>> On Mon, Sep 26, 2016 at 6:04 PM, Daniel Gryniewicz <d...@redhat.com> wrote: >>>> I believe you want to use the global filehandle embedded in the object >>>> (file.fd). You shouldn't need to add another file handle. >>> >>> I am not using mdcache in FSAL. For each call object handle is getting >>> created and released. I think I need to store one state and FD across >>> all instances, similar to following VFS FSAL code right? >>> >>> #ifdef VFS_NO_MDCACHE >>> hdl->obj_handle.state_hdl = vfs_state_locate(&hdl->obj_handle); >>> #endif /* VFS_NO_MDCACHE */ >>> >>> I don't see much code around VFS_NO_MDCACHE, is that code path >>> complete. so other FSAL's can use it as reference? ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
