> The problem is that the sub-FSAL interface was never intended to be a > general interface. It was added specifically to allow certain features to be > added to panfs, so it only has the entrypoints needed for that work. > Realistically, if I were implementing it now, I'd use a stacked FSAL, but at > the > time that wasn't possible. > > If you're working on a FSAL that's a slight variation on VFS, you might > consider > a stacked FSAL instead.
Yea, I think I'd like to see future work here use the stacked FSAL mechanism. I'm curious how FSAL_ZFS would look as a stacked FSAL (it never even made it to sub-FSAL status). On the other hand, that maybe produces more code duplication than the current implementation of FSAL_ZFS... What might be good to do is actually lay out where a new variant of FSAL_VFS has to be different and determine the best way to implement that with the smallest amount of code duplication. Frank > On 01/08/2018 11:55 AM, sriram patil wrote: > > Hmm we can use the mdcache. But wanted to store some extra > information > > from sub fsal. I guess I can do it by allocating more memory in > > vfs_sub_alloc_handle with a single malloc call. > > > > Thanks, > > Sriram > > > > On 08-Jan-2018 7:43 PM, "Frank Filz" <ffilz...@mindspring.com > > <mailto:ffilz...@mindspring.com>> wrote: > > > > Why did you want to have an additional cache? FSAL_MDCACHE already > > provides a cache of essentially every handle (though FSAL_MEM and > > FSAL_PSEUDO maintain some additional caching because those object > > handles cannot be evicted (we should actually beef up mdcache to > > genuinely prevent those handles from being evicted so they don’t > > have to do additional caching work…).____ > > > > __ __ > > > > Frank____ > > > > __ __ > > > > *From:*sriram patil [mailto:spsrirampa...@gmail.com > > <mailto:spsrirampa...@gmail.com>] > > *Sent:* Sunday, January 7, 2018 11:00 PM > > *To:* nfs-ganesha-devel@lists.sourceforge.net > > <mailto:nfs-ganesha-devel@lists.sourceforge.net> > > *Cc:* kcha...@vmware.com <mailto:kcha...@vmware.com>; > > sakt...@vmware.com <mailto:sakt...@vmware.com> > > *Subject:* Re: [Nfs-ganesha-devel] [FSAL_VFS] Probable memory leak > > when deallocating handles____ > > > > __ __ > > > > Hi,____ > > > > __ __ > > > > Sorry for the confusion here. The free should work fine because it > > is contagious memory allocated in single malloc/calloc call. > > > > The problem I wanted to address is, there is no corresponding > > vfs_sub_free_handle for vfs_sub_alloc_handle. I wanted to maintain a > > cache for every handle, once we release the handle the cache entries > > should also be evicted. Because there is no support for > > vfs_sub_free_handle, the sub fsal does not know when is the handle > > released.____ > > > > __ __ > > > > Also, it is easier if we have a void pointer in vfs_fsal_obj_handle > > to keep sub fsal specific data. This way there is no need of having > > a separate cache in sub fsal.____ > > > > __ __ > > > > Thanks,____ > > > > Sriram____ > > > > __ __ > > > > On Mon, Jan 8, 2018 at 11:58 AM, sriram patil > > <spsrirampa...@gmail.com <mailto:spsrirampa...@gmail.com>> > > wrote:____ > > > > Hi,____ > > > > __ __ > > > > I was going through the vfs_fsal_obj_handle workflow. As part of > > the function alloc_handle we allocate the handle with the help > > of vfs_sub_alloc_handle.____ > > > > __ __ > > > > vfs_sub_alloc_handle allocates vfs_fsal_obj_handle and > > vfs_file_handle_t back to back. And when releasing the handle > > (obj_ops->release), it calls free on the vfs_fsal_obj_handle. > > So, when is vfs_file_handle_t freed? Am I missing something > > here?____ > > > > __ __ > > > > Thanks,____ > > > > Sriram____ > > > > __ __ > > > > > > > > ------------------------------------------------------------------------ > > Avast logo <https://www.avast.com/antivirus> > > > > This email has been checked for viruses by Avast antivirus software. > > www.avast.com <https://www.avast.com/antivirus> > > > > > > <#m_-432962764810679348_DAB4FAD8-2DD7-40BB-A1B8- > 4E2AA1F9FDF2> > > > > > > > > ---------------------------------------------------------------------- > > -------- Check out the vibrant tech community on one of the world's > > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > Nfs-ganesha-devel mailing list > > Nfs-ganesha-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
