Hmm stackable FSAL sounds like a good option. Let me investigate on that. I
was mainly going with sub fsal because of xfs.
I agree with both of you about pushing FSAL changes to upstream. Let me see
if I can make that happen.
Thanks,
Sriram
On 08-Nov-2017 11:03 PM, "Frank Filz" <ffilz...@mindspring.com> wrote:
> > You might want to consider a stackable FSAL instead. FSAL_NULL is a good
> > example to start from. It's much more flexible than sub_fsals for VFS.
> If I
> > was implementing PanFS now, I'd use a stackable FSAL instead.
>
> Yea, this is a good point. Probably even the XFS/VFS split should be done
> with stackable FSAL.
>
> > Ganesha is LGPL specifically to allow non-FOSS FSALs. However, if the
> FSAL
> > itself does not require proprietary code, there are many advantages to
> open
> > sourcing it and getting it upstream. Not the least is that changes to
> APIs and
> > the build system will be fixed by the community, so there will be fewer
> cases
> > of sudden breakage for you to fix.
>
> On top of direct API impacts, it also helps to understand how other FSALs
> are using Ganesha so that not only do we not break the API, but don't break
> other assumptions that were made. It also is a better platform for
> requesting FSAL specific API accommodation (for a recent example, see
> compute_readdir_cookie and whence_is_name support that was added for
> FSAL_RGW, though added in a generic way so other FSALs might use it).
>
> Frank
>
> > Daniel
> >
> > On 11/08/2017 10:51 AM, sriram patil wrote:
> > > Yes, I am making a new sub fsal. May not push it to upstream because
> > > it will not be useful without the whole framework/product. As part of
> > > that, I wanted to allocate an export object which has some extra
> > > fields, other than the ones in vfs_fsal_export.
> > >
> > > Also, I hope creating a sub fsal and not making the implementation
> > > opensource does not violate any license terms.
> > >
> > > Thanks,
> > > Sriram
> > >
> > > On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz" <d...@redhat.com
> > > <mailto:d...@redhat.com>> wrote:
> > >
> > > On 11/08/2017 02:41 AM, sriram patil wrote:
> > >
> > > Hi,
> > >
> > > In the subfsal framework, I see that subfsals can have their
> own
> > > fsal_obj_handles by implementing vfs_sub_alloc_handle and then
> > > use subfsal specific variables using container_of.
> > >
> > > It does not provide same functionality for fsal_export however.
> > > There is no vfs_sub_alloc_export. vfs_create_export just calls
> > > gsh_calloc to allocate vfs_fsal_export, giving no flexibility.
> > >
> > > PANFS has its own struct panfs_fsal_export but it is not
> > > allocated anywhere. It still uses container_of on
> > > vfs_fsal_export. This looks like a memory corruption. The last
> > > commit in PANFS however is about a year back, not sure if it is
> > > actively developed.
> > >
> > >
> > > PANFS is unused and unmaintained. We keep it building, but that's
> it.
> > >
> > > Considering the above scenario, it makes sense to have
> > > vfs_sub_alloc_export to allow allocating the wrapper export
> > > object. Any thoughts?
> > >
> > >
> > > This seems like it was a bug in the original implementation for
> > > PanFS. It probably should be fixed, but the VFS sub_fsal doesn't
> > > need it, so it works for now.
> > >
> > > Are you making a new sub_fsal?
> > >
> > > Daniel
> > >
> > >
> ------------------------------------------------------------
> ----------------
> --
> > > 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
> > > <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> > > <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
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
------------------------------------------------------------------------------
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