Amar Tumballi wrote on Thu Oct 11 18:35:32 UTC 2012 : > When we initially came up with specs of 'glusterd', we needed an > option to replace a dead brick, and few people even requested for > having an option to migrate the data from the brick, when we are > replacing it. Do you specifically mean a 'dead' brick ? Or does your proposal hold for a live brick too ? (And doesn't a dead brick prevent one from reading data from it ?) > The result of this is 'gluster volume replace-brick' CLI, and in the > releases till 3.3.0 this was the only way to 'migrate' data off a > removed brick properly. > Now, with 3.3.0+ (ie, in upstream too), we have another *better* > approach (technically), which is achieved by below methods: ... > 2) (Distributed-)Replicate Volume: > > earlier: > #gluster volume replace-brick <VOL> brick1 brick2 start [1] > > now: > > #gluster volume replace-brick <VOL> brick1 brick2 commit force > (self-heal daemon takes care of syncing data from one brick to another) For a dead brick this is OK. For a live brick this would break redundancy during the long syncing time which is unacceptable. What is the live brick replace-brick 3.3.1 status and roadmap ? regards, Hans Lambermont -- Hans Lambermont | Senior Architect (t) +31407370104 (w) www.shapeways.com
