> On Thu, 2018-01-18 at 07:34 -0500, Kaleb S. KEITHLEY wrote: > > On 01/18/2018 03:23 AM, Jonathan Dieter wrote: > > > What is the best way for me to include NFS Ganesha support in LizardFS? > > > 1. Include the latest Fedora NFS Ganesha source and add a hard > requires > > > to that version in the LizardFS NFS subpackage. > > > 2. Convince the LizardFS developers to try to move their FSAL into NFS > > > Ganesha? (LizardFS has just added a client library and doesn't have > > > a server library, so this will probably take some work) > > > > That would be the path of least resistance. And the one I would > > suggest and highly recommend. If they've already written a FSAL it > > should be easy to add it to the nfs-ganesha source. > > > > Depending on the license of course. > > If this is both the easiest and the recommended path, then lets see if the > LizardFS developers will go for it. The license for this code is GPLv3.
We strongly encourage FSAL developers to have their FSAL in tree. We are friendly to FSALs for filesystems that range from proprietary (not open source) through LGPL to GPL. Ideally the FSAL code itself should be licensed LGPL and anyone distributing nfs-ganesha should definitely consult their lawyers on the implications of linking to any libraries that themselves are not LGPL. With this friendly stance, we don't require the filesystem to be included in any of the popular Linux distros, however, if the filesystem is not easily accessible it would be really helpful if a stub is included in nfs-ganesha so we can compile (IBM provides such a stub for FSAL_GPFS). The huge advantage here is communication with the nfs-ganesha team on the requirements of the FSAL on nfs-ganesha's infrastructure. We have made many changes outside the FSALs to help individual FSALs. Also, if we can at least compile an FSAL, when we make API changes, we will try and make sure all in tree FSALs at least still compile and we've made more extensive changes also. > > > 3. Convince the NFS Ganesha developers to create a library that you can > > > compile FSAL's against? (The last thread I saw in the NFS Ganesha > > > devel list on this subject was six years old) > > > > That would be a non-trivial amount of work with little benefit to the > > current FSAL developers. > > > > It's not an unreasonable request, per se, but we have other, higher > > priorities. > > I totally understand that. One danger of this path is that we make subtle changes to the FSAL API that are do not necessarily result in us changing the FSAL API version. And the changes are not necessarily even something that would cause a compilation or link error. Sometimes there is a change in assumptions of responsibility or the range of acceptable values for a parameter. > > > 4. ??? > > > > > > Any advice would be great, as I'd love to get this feature into > > > Fedora's release of LizardFS. > > > > Do you have a contact for someone at LizardFS? I looked at their web > > site and nothing popped out at me. > > The main developer that I've communicated with is: > Piotr Sarna <sa...@skytechnology.pl> > > Jonathan > > ---------------------------------------------------------------------------- -- > 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
