[Gluster-users] gluster replacing a brick

[Shyamsundar Ranganathan]

> From: "Hariharan Thantry" <thantry at gmail.com>
> To: "Shyamsundar Ranganathan" <srangana at redhat.com>
> Cc: gluster-users at gluster.org
> Sent: Friday, January 31, 2014 11:10:41 AM
> Subject: Re: [Gluster-users] gluster replacing a brick

> Shyam,

> Thanks. What would be *extremely* useful is the ability to move data off the
> brick just through replace brick, where the other identified brick is a
> member of the current cluster (Isn't that something that would be natural?)

Remove brick goes with rebalance, which places data is the brick appropriate to the gluster internal hash algo. hence enabling finding the file and its contents with the least number of hops and lookups. Moving data from one brick to another (which in this case are locally hosted) may seem faster, but could cause an imbalance in the cluster, which _could_ then later show itself up as a slow access to files metadata.

> The *real* issue for me is that my disk hosts multiple bricks, each of whose
> replicas are on other bricks (higher redundancy). You can't "remove" a brick
> without taking out its replica as well. Wouldn't it be much simpler for
> Gluster to be able to manage this in the backend through replace-brick?

Ummm... yes that is true. This is the way it is supported as of now.

Replace brick just needs a fresh brick, it is not _merge_ bricks, which is more like what you are looking for and put that way maybe useful for other scenarios as well.

Shyam