I would actually like to see the sub-FSAL removed, and xfs converted to a stacked FSAL at some point, now that patfs is dead. But it's not high on my list (especially with testing xfs...)
Daniel On Mon, Jan 8, 2018 at 3:15 PM, Frank Filz <ffilz...@mindspring.com> wrote: >> 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
