On Wed, Sep 28, 2016 at 12:33 PM, Frank Filz <ffilz...@mindspring.com> wrote:
>> Is this global file descriptor should be maintained in similar sturct like >> vfs_locate_state? I expect it to work without mdcache. > > I have yet to explore all the implications of no MDCACHE. I believe the > existence of vfs_locate_state maintains a reference on the fsal_obj_handle, > in which case, you can still keep the global fd in the fsal_obj_handle (and > presumably you would still want to do that since stateless I/O requests will > come into the FSAL call with no pointer to a state_t and you may not want to > take the effort of looking up the vfs_locate_state. On the other hand, I'm > not sure how the upper layers get an fsal_obj_handle reference in that case... The vfs_state_entry does not maintain a refcount on the fsal_obj_handle (which has no refcount of it's own; refcounting is provided by MDCACHE). Instead, it is persisted in a tree keyed on the object key of the handle it's associated with. So, the obj_handle itself will come and go, while the vfs_state_entry persists. Likely the global FD used for locking would need to be added to the vfs_state_entry, or a special state_t added that contains it. Daniel ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
