Re: [Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
H. Keep me CCed, please, because for a couple last months I do not follow GlusterFS development… On pátek 3. března 2017 21:50:07 CET Niels de Vos wrote: > At the moment we have three top-level interfaces to maintain in Gluster, > these are FUSE, Gluster/NFS and gfapi. If any work is needed to support > new options, FOPs or other functionalities, we mostly have to do the > work 3x. Often one of the interfaces gets forgotten, or does not need > the new feature immediately (backlog++). This is bothering me every now > and then, specially when bugs get introduced and need to get fixed in > different ways for these three interfaced. > > One of my main goals is to reduce the code duplication, and move > everything to gfapi. We are on a good way to use NFS-Ganesha instead of > Gluster/NFS already. In a similar approach, I would love to see > deprecating our xlators/mount sources[0], and have it replaced by > xglfs[1] from Oleksandr. > > Having the FUSE mount binaries provided by a separate project should > make it easier to implement things like subdirectory mounts (Samba and > NFS-Ganesha already do this in some form through gfapi). > > xglfs is not packaged in any distribution yet, this allows us to change > the current commandline interface to something we deem more suitable (if > so). > > I would like to get some opinions from others, and if there are no > absolute objections, we can work out a plan to make xglfs an alternative > to the fuse-bridge and eventually replace it. > > Thanks, > Niels > > > 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount > 1. https://github.com/gluster/xglfs ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
> At the moment we have three top-level interfaces to maintain in > Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed > to support new options, FOPs or other functionalities, we mostly have > to do the work 3x. Often one of the interfaces gets forgotten I think the picture's a bit more complicated than that. When core features are added, supporting them often requires work in Ganesha and/or Samba as well as GFAPI. Indeed, those are often the only things driving that core work, and the results aren't even accessible via FUSE. In those cases, the technical underpinnings of our FUSE translator won't matter at all. Even when FUSE *is* involved, the work necessary to update xfuse will still be non-zero. Adding a feature to GFAPI doesn't magically add it to every GFAPI-based interface. We'll still have to do a lot of work 3x, and I bet we'll still forget to update them all sometimes. > Yes, there are definitely a lot of features that we need to add. That's the key. While I like the idea of switching to an xglfs-based solution in principle, I think we need a clearer picture of what work still needs to be done *before* we can make more concrete plans. Does every kind of notify (including that GF_EVENT_AUTH_FAILED hack) work the same in xglfs as now? Do graph switches work the same? What about performance or memory use? When we know those answers, and more that might fall out from running a prototype through our existing regression tests, then we can weigh that against the improved maintainability of the newer code. Until then, we're kind of guessing. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
On Fri, Mar 03, 2017 at 12:58:12PM -0800, Joe Julian wrote: > The only concern I have is that according to the README syntax (I haven't > looked any deeper but I suspect it's a non issue) there's a lack of rdma > support. Yes, there are definitely a lot of features that we need to add. This is one of the issues that needs solving. Our FUSE exposes many more options than gfapi applications can set, I'm looking at extending the gfapi interface[2]for these as well. We'll need to test and extend gfapi+xglfs over a few releases before this really can completely replace the current FUSE support. Thanks, Niels 2. http://lists.gluster.org/pipermail/gluster-devel/2017-March/052228.html > Otherwise I'm all for anything that simplifies bug fixing and improves > stability. > > > On 03/03/2017 12:50 PM, Niels de Vos wrote: > > At the moment we have three top-level interfaces to maintain in Gluster, > > these are FUSE, Gluster/NFS and gfapi. If any work is needed to support > > new options, FOPs or other functionalities, we mostly have to do the > > work 3x. Often one of the interfaces gets forgotten, or does not need > > the new feature immediately (backlog++). This is bothering me every now > > and then, specially when bugs get introduced and need to get fixed in > > different ways for these three interfaced. > > > > One of my main goals is to reduce the code duplication, and move > > everything to gfapi. We are on a good way to use NFS-Ganesha instead of > > Gluster/NFS already. In a similar approach, I would love to see > > deprecating our xlators/mount sources[0], and have it replaced by > > xglfs[1] from Oleksandr. > > > > Having the FUSE mount binaries provided by a separate project should > > make it easier to implement things like subdirectory mounts (Samba and > > NFS-Ganesha already do this in some form through gfapi). > > > > xglfs is not packaged in any distribution yet, this allows us to change > > the current commandline interface to something we deem more suitable (if > > so). > > > > I would like to get some opinions from others, and if there are no > > absolute objections, we can work out a plan to make xglfs an alternative > > to the fuse-bridge and eventually replace it. > > > > Thanks, > > Niels > > > > > > 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount > > 1. https://github.com/gluster/xglfs > > > > > > ___ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://lists.gluster.org/mailman/listinfo/gluster-devel > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
The only concern I have is that according to the README syntax (I haven't looked any deeper but I suspect it's a non issue) there's a lack of rdma support. Otherwise I'm all for anything that simplifies bug fixing and improves stability. On 03/03/2017 12:50 PM, Niels de Vos wrote: At the moment we have three top-level interfaces to maintain in Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed to support new options, FOPs or other functionalities, we mostly have to do the work 3x. Often one of the interfaces gets forgotten, or does not need the new feature immediately (backlog++). This is bothering me every now and then, specially when bugs get introduced and need to get fixed in different ways for these three interfaced. One of my main goals is to reduce the code duplication, and move everything to gfapi. We are on a good way to use NFS-Ganesha instead of Gluster/NFS already. In a similar approach, I would love to see deprecating our xlators/mount sources[0], and have it replaced by xglfs[1] from Oleksandr. Having the FUSE mount binaries provided by a separate project should make it easier to implement things like subdirectory mounts (Samba and NFS-Ganesha already do this in some form through gfapi). xglfs is not packaged in any distribution yet, this allows us to change the current commandline interface to something we deem more suitable (if so). I would like to get some opinions from others, and if there are no absolute objections, we can work out a plan to make xglfs an alternative to the fuse-bridge and eventually replace it. Thanks, Niels 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount 1. https://github.com/gluster/xglfs ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
At the moment we have three top-level interfaces to maintain in Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed to support new options, FOPs or other functionalities, we mostly have to do the work 3x. Often one of the interfaces gets forgotten, or does not need the new feature immediately (backlog++). This is bothering me every now and then, specially when bugs get introduced and need to get fixed in different ways for these three interfaced. One of my main goals is to reduce the code duplication, and move everything to gfapi. We are on a good way to use NFS-Ganesha instead of Gluster/NFS already. In a similar approach, I would love to see deprecating our xlators/mount sources[0], and have it replaced by xglfs[1] from Oleksandr. Having the FUSE mount binaries provided by a separate project should make it easier to implement things like subdirectory mounts (Samba and NFS-Ganesha already do this in some form through gfapi). xglfs is not packaged in any distribution yet, this allows us to change the current commandline interface to something we deem more suitable (if so). I would like to get some opinions from others, and if there are no absolute objections, we can work out a plan to make xglfs an alternative to the fuse-bridge and eventually replace it. Thanks, Niels 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount 1. https://github.com/gluster/xglfs signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
