On Tue, May 2, 2017 at 12:20 AM, Gandalf Corvotempesta < [email protected]> wrote:
> 2017-05-01 20:43 GMT+02:00 Shyam <[email protected]>: > > I do agree that for the duration a brick is replaced its replication > count > > is down by 1, is that your concern? In which case I do note that without > (a) > > above, availability is at risk during the operation. Which needs other > > strategies/changes to ensure tolerance to errors/faults. > > Oh, yes, i've forgot this too. > > I don't know Ceph, but Lizard, when moving chunks across the cluster, > does a copy, not a movement > During the whole operation you'll end with some files/chunks > replicated more than the requirement. > Replace-brick as a command is implemented with the goal of replacing a disk that went bad. So the availability was already less. In 2013-2014 I proposed that we do it by adding brick to just the replica set and increase its replica-count just for that set once heal is complete we could remove this brick. But at the point I didn't see any benefit to that approach, because availability was already down by 1. But with all of this discussion it seems like a good time to revive this idea. I saw that Shyam suggested the same in the PR he mentioned before. > > If you have a replica 3, during the movement, some file get replica 4 > In Gluster the same operation will bring you replica 2. > > IMHO, this isn't a viable/reliable solution > > Any change to change "replace-brick" to increase the replica count > during the operation ? > It can be done. We just need to find time to do this. -- Pranith
_______________________________________________ Gluster-users mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
