On 07/28/2015 03:51 PM, Frank Filz wrote: <snip> > > I was avoiding the free standing blob (at least for NFS, 9p it was not so > easy), so for NFS state_t objects, the fsal_fd is allocated along with the > state_t. > > The FSAL has to be able to indicate how much space it needs. > > Yes, we COULD pass the state_t (still needs to allocate some space for FSAL > somehow) instead of the fsal_fd. The question I have is what in there is of > value to the FSAL. If there really is something of value, then sure, let's > pass the state_t. Without something of value though, I'm wary of exposing > state_t stuff to the FSAL (for one thing it's protected by the state_lock, > which the FSAL normally doesn't have access to). > > However, there is another hitch... When doing an open/create, we don't have a > cache entry or state_t yet (which currently means fsal_fd is actually > something that needs to be able to be copied). >
In my MDCACHE work, the state_t is completely allocated by the FSAL, since it has to (potentially) store it as well, if there's no MDCACHE layer for that FSAL. So, it can just layer state_t, like it layers fsal_obj_handle. The advantage of this is that it looks and behaves just like object handles, exports, and other things that the FSAL already layers. Under this paradigm, open/create would return the state_t as an out param anyway. If this is interesting, the code to call into the FSAL to get/put the state is fairly separable, and can go in soon. Dan ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
