<div dir="ltr"><div class="gmail_quote"><div>Hi Stefan,</div><div><br></div><div>Some responses inline (Adding to already expressed opinions from few users, and some developers).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">From: <strong class="gmail_sendername" dir="auto">Stefan</strong> <span dir="auto"><<a href="mailto:gluster@stefanseidel.info" target="_blank">gluster@stefanseidel.info</a>></span><br>Date: Wed, Feb 12, 2020 at 3:34 AM<br></div><br>Hi,<br>
<br>
looking through the last couple of week on this mailing list and reflecting our own experiences, I have to ask: what is the status of GlusterFS?</div></div></blockquote><div><br></div><div>Status is surely 'Active'. Considering the project is of 13+ yrs, treat current mode is 'low tide' in activity wave. But I want to assure, being a maintainer, I would like to keep the project active and will continue to solve use-cases where it fits well.<br></div><div><br></div><div>Also, if you notice, we just recently had Release-8 planning meeting, and the scope and future of the project leading to GlusterX (GlusterFS 10 release) is being discussed. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"> So many people here reporting bugs and no solutions are in sight.</div></div></blockquote><div><br></div><div><div>Sorry about that. I have to accept the statement with a pinch of salt. There is no 'good' answer when a user is unhappy. But I want to write a long answer for this particular point.</div><div><br></div><div>Like any 'open source' project, there are few commercially supporting Enterprises backing Gluster, who still have many developers engaged in making sure the project is active. But the fact is, a developer can pick an issue to fix based on their 'employer' priorities. Sometimes, it so happens that the usecases where there are problems in glusterfs may not be a priority for most of the developers due to their employer priority. </div><div><br></div><div>As an individual contributor/maintainer for the project, the biggest challenge in picking and fixing the issues which are complicated can be listed like below:</div><div><br></div><div>* The problem may not happen when there is lesser load, or scale. Which means, the fix would still be based on 'speculation' or 'knowing the code'. Validate our fixes at scale is a challenge without a company support.</div><div>* We may not be able to reproduce the issue, which again would delay the fix.</div><div>* The project itself deals with 'data', so many users may not be able to provide more information, which again makes the delay.</div><div><br></div><div>All these issues aside, I want to take time and appreciate those users who actively answer queries of fellow users, and keep the lights on in the community. It is one of the major contributions anyone can give back to an opensource community.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"> GlusterFS clusters break left and right, reboots of a node have become a warrant for instability and broken clusters, no way to fix broken clusters. And all of that with recommended settings, and in our case, enterprise hardware underneath.<br></div></div></blockquote><div><br></div><div style="color:rgb(80,0,80)"><div>I should acknowledge the 'documentation', which would have 'recommended' setup, is possibly out of date! We are on to fixing the documentation right now..</div><div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">
Is it time to abandon this for production systems?<br></div></div></blockquote><div><br></div><div>This is a very critical question. As person responsible for running an infra for my company, I surely should be asking this question, especially if things are not working out. Nothing wrong in you asking this. I would say if you have production systems, consider talking to companies who support the project etc, and have the alternative options properly thought of.<br></div><div><br></div><div>If interested, I am happy to make time and we can talk about particular issues, and what do you expect to see, and give feedback. After that, you can take decision on this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">
What are the alternatives?<br></div></div></blockquote><div><br></div><div><div>Not a good person to answer. But would be great to know alternatives, so we also learn what more we can do here.</div></div><div> </div><div>Regards,</div><div>-Amar Tumballi</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">
Looking through the solutions, CephFS might be one, but it doesn't seem to be very fast. MooseFS would be one, but it only support RAID-1 style replication, no arbiter and Erasure Coding only in the Pro version.<br>
Tahoe-LAFS is geared towards a different use case.<br>
Any other suggestions?<br>
<br>
Thanks,<br>
<br>
Stefan<br>
________</div></div></blockquote></div></div>