<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 10, 2017 at 4:09 PM, Cedric Lemarchand <span dir="ltr"><<a href="mailto:yipikai7@gmail.com" target="_blank">yipikai7@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 10 Mar 2017, at 10:33, Alessandro Briosi <<a href="mailto:ab1@metalit.com">ab1@metalit.com</a>> wrote:<br>
><br>
> Il 10/03/2017 10:28, Kevin Lemonnier ha scritto:<br>
>>> I haven't done any test yet, but I was under the impression that<br>
>>> sharding feature isn't so stable/mature yet.<br>
>>> In the remote of my mind I remember reading something about a<br>
>>> bug/situation which caused data corruption.<br>
>>> Can someone confirm that sharding is stable enough to be used in<br>
>>> production and won't cause any data loss?<br>
>> There were a few bugs yeah. I can tell you that in 3.7.15 (and I assume<br>
>> later versions) it works well as long as you don't try to add new bricks<br>
>> to your volumes (we use it in production for HA virtual machine disks).<br>
>> Apparently that bug was fixed recently, so latest versions should be<br>
>> pretty stable yeah.<br>
><br>
> I'm using 3.8.9, so I suppose all known bugs have been fixed there (also the one with adding briks)<br>
><br>
> I'll then proceed with some tests before going to production.<br>
<br>
</span>I am still asking myself how such bug could happen on a clustered storage software, where adding bricks is a base feature for scalable solution, like Gluster. Or maybe is it that STM releases are really under tested compared to LTM ones ? Could we states that STM release are really not made for production, or at least really risky ?<br></blockquote><div><br></div><div>Not entirely true. The same bug existed in LTM release too.<br><br>I did try reproducing the bug on my setup as soon as Lindsay, Kevin and others started reporting about it, but it was never reproducible on my setup.<br></div><div>Absence of proper logging in libgfapi upon failures only made it harder to debug, even when the users successfully recreated the issue and shared<br></div><div>their logs. It was only after Satheesaran recreated it successfully with FUSE mount that the real debugging could begin, when fuse-bridge translator<br></div><div>logged the exact error code for failure.<br></div><div><br></div><div>-Krutika<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sorry if the question could sounds a bit rude, but I think it still remains for newish peoples that had to make a choice on which release is better for production ;-)<br>
<br>
Cheers<br>
<br>
Cédric<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thank you<br>
><br>
> ______________________________<wbr>_________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
> <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-users</a><br>
<br>
______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-users</a></div></div></blockquote></div><br></div></div>