Gluster users - Nov 2016 - 3.7.16 with sharding corrupts VMDK files when adding and removing bricks

2016-11-14 15:54 GMT+01:00 Niels de Vos <ndevos at
redhat.com>:
> 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. "
> 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.

Yes. I apologise for the delay.

Disabling sharding would knock the translator itself off the client stack,
and
being that sharding is the actual (and the only) translator that has the
knowledge of how to interpret sharded files, and how to aggregate them,
removing the translator from the stack will make all shards start to appear
like
isolated files with no way to interpret the correlation between the
individual pieces.

The only way to fix it is to have sharding be part of the graph *even* if
disabled,
except that in this case, its job should be confined to aggregating the
already
sharded files during reads but NOT shard new files that are created, since
it is
supposed to "act" disabled. This is a slightly bigger change and this
is
why I had
suggested the workaround at
https://bugzilla.redhat.com/show_bug.cgi?id=1355846#c1
back then.

FWIW, the documentation [1] does explain how to disable sharding the right
way and has been in existence ever since sharding was first released in
3.7.0.

[1] - http://staged-gluster-docs.readthedocs.io/en/release3.7.
0beta1/Features/shard/

-Krutika



On Mon, Nov 14, 2016 at 9:08 PM, Gandalf Corvotempesta <
gandalf.corvotempesta at gmail.com> wrote:
> 2016-11-14 15:54 GMT+01:00 Niels de Vos <ndevos at redhat.com>:
> > 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. "
>
> > 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.
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20161114/5e07b048/attachment.html>

On Mon, Nov 14, 2016 at 10:38 AM, Gandalf Corvotempesta
<gandalf.corvotempesta at gmail.com> wrote:
> 2016-11-14 15:54 GMT+01:00 Niels de Vos <ndevos at redhat.com>:
>> 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