This was originally a response on Quora, but it ended up attached to a comment that got downvoted (not by me) and that makes it hard to find so I figured I’d give it some more exposure here. I’ll add some more Gluster-specific commentary at the end, but first I just have to re-use the graphic from my original answer.
Here’s how I outlined some of the steps. They might look familiar.
At this point you’ll be at approximate parity with the other distributed filesystems out there. Most of these steps should take about half to two months for a suitably skilled individual working full time or nearly so, plus another couple of months for generic stuff like FUSE interfaces and connection management, so you’re looking at a bit over a year. Triple everything if you decide to do it all in the kernel instead, and triple again if you want to make it production quality.
OK, so why did GlusterFS in user space take even longer than that? The first reason is the time in which it was written. Many of the techniques that now seem obvious were very poorly understood (by anyone) at the time, which meant a lot of experimenting and often backtracking. Some components had to be replaced multiple times. Many of the things we depend on, such as FUSE, didn’t work all that well at the time either. Secondly, that same industry-wide unfamiliarity meant that recruiting and training developers and testers was much harder. That meant reduced hands-on productivity both from the new folks (at each iteration) and from the old folks who became mentors. Thirdly, and I think most significantly, the constraints of having been in production and having to deal with actual customer bugs played a part. It’s not easy to drain the swamp when you’re up to your a~~ in alligators, and it’s not easy to write new code when you’re at a customer site fixing the old stuff. If you look at other serious distributed filesystems of approximately the same vintage, you’ll see the same thing. (Don’t even get me started on the planetary waste of brainpower that NFS has been over the same period.) It would be feasible for a single person to develop a semi-decent distributed filesystem in a year or so now (I think about that all the time) but that most certainly wasn’t true in 2006. We’ll all be developing more rapidly now, adding features left and right. Keep that in mind as you evaluate each new announcement and try to guess who’s going to be ahead in another year or two.
2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...
It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...
The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...