i.e., I like that it captures the idea (in multi-fd already) to allocate all at once, and this is how I would have intuited we move to opaque user data.
I think we can deal with whatever workaround solves locking currently required for that object (e.g., Adam's suggestion to call up into SAL layer in some cases), esp. since iirc an eventual step in Dan's MDCACHE work involved lock reorganization, and a lot things will likely shake out from that? Matt ----- "Matt W. Benjamin" <m...@cohortfs.com> wrote: > 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 -- 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
