> 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...)
I'll take a look at it for early V2.7, it should be quick. I have an XFS filesystem and export, so easy enough to test (and no upcalls...). I am concerned about duplicate code since XFS differs almost exclusively in the system calls made to implement open by handle, otherwise, the logic is the same. Let's see how it looks and then decide. The other option is to actually deprecate FSAL_XFS, but I don't know if we can afford to shut out older kernels and distros... Frank > 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
