<html><head></head><body>Features and stability are not mutually exclusive. <br>
<br>
Sometimes instability is cured by adding a feature. <br>
<br>
Fixing a bug is not something that's solved better by having more developers work on it.<br>
<br>
Sometimes fixing one bug exposed a problem elsewhere. <br>
<br>
Using free open source community projects with your own hardware and system design weights the responsibility to test more heavily on yourself. If that's not a risk you can afford, you might consider contracting with a 3rd party which has "certified" installation parameters. IMHO.<br><br><div class="gmail_quote">On November 14, 2016 8:29:00 AM PST, Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">1016-11-14 17:01 GMT+01:00 Vijay Bellur <vbellur@redhat.com>:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Accessing sharded data after disabling sharding is something that we<br /> did not visualize as a valid use case at any point in time. Also, you<br /> could access the contents by enabling sharding again. Given these<br /> factors I think this particular problem has not been prioritized by<br /> us.<br /></blockquote><br />That's not true.<br />If you have VMs running on a sharded volume and you disable sharding,<br />with the VM still running, everything crash and could lead to data loss, as VM<br />will be unable to find their filesystem and so on, qemu currupts the<br />image and so on.....<br /><br />If I write to a file that was shareded, (in example a log file), now<br />when you disable the shard,<br />the application would write the existing file (the one that was
the<br />first shard).<br />If you reenable sharding, you lost some data<br /><br />Example:<br /><br />128MB file. shard set to 64MB. You have 2 chunks: shard1+shard2<br /><br />Now you are writing to the file:<br /><br />AAAA<br />BBBB<br />CCCC<br />DDDD<br /><br />AAAA+BBBB are placed on shard1, CCCC+DDDD are placed on shard2<br /><br />If you disable the shard and write some extra data, EEEE, then EEEE<br />would be placed after BBBB in shard1 (growing more than 64MB)<br />and not on shard3<br /><br />If you re-enable shard, EEEE is lost, as gluster would expect it as<br />shard3. and I think gluster will read only the first 64MB from shard1.<br />If gluster read the whole file, you'll get something like this:<br /><br />AAAA<br />BBBB<br />EEEE<br />CCCC<br />DDDD<br /><br />in a text file this is bad, in a VM image, this mean data<br />loss/corruption almost impossible to fix.<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px
solid #729fcf; padding-left: 1ex;"> As with many other projects, we are in a stage today where the number<br /> of users and testers far outweigh the number of developers<br /> contributing code. With this state it becomes hard to prioritize<br /> problems from a long todo list for developers. If valuable community<br /> members like you feel strongly about a bug or feature that need<br /> attention of developers, please call such issues out on the mailing<br /> list. We will be more than happy to help.<br /></blockquote><br />That's why i've asked for less feature and more stability.<br />If you have to prioritize, please choose all bugs that could lead to<br />data corruption or similiar.<br /><hr /><br />Gluster-users mailing list<br />Gluster-users@gluster.org<br /><a href="http://www.gluster.org/mailman/listinfo/gluster-users">http://www.gluster.org/mailman/listinfo/gluster-users</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>