Re: Add single server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, May 1, 2017 at 9:53 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:


On Sun, Apr 30, 2017 at 2:04 PM, Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com> wrote:
2017-04-30 10:13 GMT+02:00  <lemonnierk@xxxxxxxxx>:
> I was (I believe) the first one to run into the bug, it happens and I knew it
> was a risk when installing gluster.

I know.

> But since then I didn't see any warnings anywhere except here, I agree
> with you that it should be mentionned in big bold letters on the site.
>
> Might even be worth adding a warning directly on the cli when trying to
> add bricks if sharding is enabled, to make sure no-one will destroy a
> whole cluster for a known bug.

Exactly. This is making me angry.

Even $BigVendor usually release a security bulletin, in example:
https://support.citrix.com/article/CTX214305
https://support.citrix.com/article/CTX214768

Immediatly after discovering that bug, a report was made available (on
official website, not on a mailinglist)
telling users which operations should be avoided until a fix is made.

Gluster don't. There is a huge bug that isn't referenced in official docs.

Is not acting like a customer, i'm just asking for some transparancy.

Even if this is an open source project, nobody should play with user data.
This bug (or, better, these bugs) are know from time, an there is NO WORDS
in any official docs nor the web site.

is not a rare bug, it *always* loose data when used with VMs and
sharding during a rebalance.
this feature should be disabled or users should be warned somewhere on
web site and not forcing
all of them to look through ML archives.

Anyway, i've just asked for a feature like simplifying the add-brick
process. Gluster devs are free to ignore it
but if they are interest in something similiar, i'm willing to provide
more info (if I can, i'm not a developer)

I really love gluster, lack of metadata server is awesome, files
stored "verbatim" with no alteration is amazing (almost all SDS alter
file when stored on disks)
but being forced to add bricks in a multiple of replica count is
making gluster very expesive (yes, there is a workaround with multiple
steps, but this is prone to
error, thus i'm asking to simplify this phase allowing users to add a
single brick to a replica X volume with automatic member replacement
and rebalance)

IMHO It is difficult to implement what you are asking for without metadata server which stores where each replica is stored.

Anther way is probably loading replica on top of distribute, but that is architecture change and may need lot of testing and fixing corner cases. I don't think it is easier to get this done.
 
 
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users



--
Pranith



--
Pranith
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux