> 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.
Note that FSALs intended for use without MDCACHE are refcounted, they MUST implement get_ref and put_ref. I'm not sure how that interacts with vfs_locate_state since I think the refcount requirement was put in after the brief test period of cacheless FSAL_VFS. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
