|
On 02/23/2013 01:40 AM, Anand Avati
wrote:
Avati, Basically I want to understand the usecase the current implementation is trying to address. The problem I am concerned at the moment are the ones about data on different replicas. Especially the meaning of changelog it introduces on the files. It seems we can come up with use cases where the order of the replica subvolumes can change. Ex: We can change replica old subvol-0 change log to be referred by subvol-1. gluster --mode=script volume create r2 replica 2 pranithk-laptop:/home/gfs/r2_0 pranithk-laptop:/home/gfs/r2_1 volume create: r2: success: please start the volume to access data gluster --mode=script volume start r2 volume start: r2: success gluster --mode=script volume set r2 client-log-level DEBUG volume set: success gluster --mode=script volume set r2 brick-log-level DEBUG volume set: success mkdir: cannot create directory `/mnt/r2': File exists gluster volume add-brick r2 replica 3 pranithk-laptop:/home/gfs/r2_2 volume add-brick: success gluster volume remove-brick r2 replica 2 pranithk-laptop:/home/gfs/r2_0 Removing brick(s) can result in data loss. Do you want to Continue? (y/n) y volume remove-brick commit force: success gluster volume info Volume Name: r2 Type: Replicate Volume ID: 0e3eac61-5b99-455a-a0fc-818138d0ce1e Status: Started Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: pranithk-laptop:/home/gfs/r2_1 Brick2: pranithk-laptop:/home/gfs/r2_2 This can potentially change the direction of self-heal. I was not able to find any documentation about this feature, except this http://community.gluster.org/q/volume-type-changes-supported-in-3-3-0/ The example I gave above is supported according to the link above, which is not good IMO. So I am trying to gather information about the status of this feature's implementation. What exact use cases are we trying to address? Pranith. |
