On Mon, Nov 14, 2016 at 10:38 AM, Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx> wrote: > 2016-11-14 15:54 GMT+01:00 Niels de Vos <ndevos@xxxxxxxxxx>: >> Obviously this is unacceptible for versions that have sharding as a >> functional (not experimental) feature. All supported features are >> expected to function without major problems (like corruption) for all >> standard Gluster operations. Add-brick/replace-brick are surely such >> Gluster operations. > > Is sharding an experimental feature even in 3.8 ? > Because in 3.8 announcement, it's declared stable: > http://blog.gluster.org/2016/06/glusterfs-3-8-released/ > "Sharding is now stable for VM image storage. " > sharding was an experimental feature in 3.7. Based on the feedback that we received in testing, we called it out as stable in 3.8. The add-brick related issue is something that none of us encountered in testing and we will determine how we can avoid missing such problems in the future. >> FWIW sharding has several open bugs (like any other component), but it >> is not immediately clear to me if the problem reported in this email is >> in Bugzilla yet. These are the bugs that are expected to get fixed in >> upcoming minor releases: >> https://bugzilla.redhat.com/buglist.cgi?component=sharding&f1=bug_status&f2=version&o1=notequals&o2=notequals&product=GlusterFS&query_format=advanced&v1=CLOSED&v2=mainline > > My issue with sharding was reported in bugzilla on 2016-07-12 > 4 months for a IMHO, critical bug. > > If you disable sharding on a sharded volume with existing shared data, > you corrupt every existing file. Accessing sharded data after disabling sharding is something that we did not visualize as a valid use case at any point in time. Also, you could access the contents by enabling sharding again. Given these factors I think this particular problem has not been prioritized by us. As with many other projects, we are in a stage today where the number of users and testers far outweigh the number of developers contributing code. With this state it becomes hard to prioritize problems from a long todo list for developers. If valuable community members like you feel strongly about a bug or feature that need attention of developers, please call such issues out on the mailing list. We will be more than happy to help. Having explained the developer perspective, I do apologize for any inconvenience you might have encountered from this particular bug. Thanks! Vijay _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
