This feels to be on the right track. Matt
----- "Daniel Gryniewicz" <d...@redhat.com> wrote: > 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 -- Matt Benjamin CohortFS, LLC. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://cohortfs.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
