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.
Daniel
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
