I think it's viable consideration. As the port maintainer I've seen first hand what the "behind the scenes" process is upstream. They haven't rejected FreeBSD as a target, but at the same time they are unwilling to provide a sufficient amount of resources and attention towards making sure it works properly. It's perfectly understandable, the primary focus of GlusterFS is Linux.
I don't think we gain anything by following the main GlusterFS project. In fact, I think it holds back the potential of what could be a tier 1 replicated file service for FreeBSD. I haven't seen much innovation being done on GlusterFS in the past few years. If anything, the 'innovation' is very Linux specific. By forking GlusterFS, we could remove a lot of the buggy code that's designed to work only on Linux.
As many here are aware, the net/glusterfs port is currently broken, but not by an upstream change. The breakage was a result of some change in FreeBSD ports or dependency. One of the reason's I'm hesitating to fix it, is that GlusterFS on FreeBSD never really worked to begin with. I don't want to give people a false sense of security by putting something out there that's going to result in data loss (it will).
There's a lot of spaghetti code in the startup/initialization stage of GlusterFS that makes porting the IO multiplexing to kqueue/kevent challenging. Forking GlusterFS and reworking that code to work on FreeBSD without having to worry about Linux would be the optimal way forward in my opinion. We can't use the shim for reason's I've already shared in other posts (ie. process forking).
My premilinary roadmap (should this happen)
For an MVP
While I can handle the MVP for the most part, I don't posses the skills/experiance of a seasoned C developer. So this may take a few years since this is a side project for me.
Would there be any interest and support for such a crazy idea?
I don't think we gain anything by following the main GlusterFS project. In fact, I think it holds back the potential of what could be a tier 1 replicated file service for FreeBSD. I haven't seen much innovation being done on GlusterFS in the past few years. If anything, the 'innovation' is very Linux specific. By forking GlusterFS, we could remove a lot of the buggy code that's designed to work only on Linux.
As many here are aware, the net/glusterfs port is currently broken, but not by an upstream change. The breakage was a result of some change in FreeBSD ports or dependency. One of the reason's I'm hesitating to fix it, is that GlusterFS on FreeBSD never really worked to begin with. I don't want to give people a false sense of security by putting something out there that's going to result in data loss (it will).
There's a lot of spaghetti code in the startup/initialization stage of GlusterFS that makes porting the IO multiplexing to kqueue/kevent challenging. Forking GlusterFS and reworking that code to work on FreeBSD without having to worry about Linux would be the optimal way forward in my opinion. We can't use the shim for reason's I've already shared in other posts (ie. process forking).
My premilinary roadmap (should this happen)
For an MVP
- Remove Linux specific code
- Intigrate FreeBSD 'hacks' and patchs into main codebase
- Remove 'poll' system calls code (it's broken beyond repair)
- Replace IO multiplexing from epoll to kqueue/kevent
- Evaluate state of supporting tools in code base
- Fix remaining bugs/porting to FreeBSD
- Look at the possiblity of converting the gluster fusefs driver into an actual kernel module
While I can handle the MVP for the most part, I don't posses the skills/experiance of a seasoned C developer. So this may take a few years since this is a side project for me.
Would there be any interest and support for such a crazy idea?
.