On Thu, Nov 9, 2017 at 1:33 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > On Thu, Nov 09, 2017 at 01:04:48AM +0100, Csaba Henk wrote: > > Hello list, > > > > here is an overview of recent additions to the > > FUSE protocol that are not yet supported by > > the GlusterFS FUSE implementation and > > what sh/could be done about them. > > > > https://docs.google.com/document/d/1VGxMC7Db7Rdd19VXlBe0tI-frdjICJdzxx4EsntuPDU/edit > > > > Comments on the doc or in this thread are most > > warmly welcome. > > I would really love to see us use libfuse (not a forked or bundled > version) with libgfapi. That should make it easier for us to follow > upstream enhancements. A proof of concept was once written by Olegsandr > Natalenko and is available at https://github.com/gluster/xglfs > > Maintaining three access xlators/protocols (FUSE, gNFS, gfapi) adds a > lot of overhead. Having a single one (gfapi) with additional projects > for the other 'bindings' to protocols would be much better to maintain. > > There was a bug or issue for this somewhere... I'm not able to find it > though. I harbored an unresolved unease about depending on libfuse, kind of a memory of a thought that it is does not do good to us to have it, but forgot about the reason. Recently I managed to pin it down - it was from the pre-acquisition days, when on customers' setups libfuse was either unavailable or only a fairly out of date version, which was the cause of many headaches. So - nothing inherent to libfuse and nothing that would be relevant as of today. But then, let me put it like this: what reason could we have to *not* go with xglfs in 4.0? It's true that the deliverables are present in libfuse and libgfapi and it's just a thin glue. As such it seems to be almost devoid of design concerns, it just bridges the two interfaces in a straightforward manner. Superficially it seems to be a superior approach - what snag holds us back to embrace it wholeheartedly? Csaba _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
