<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/23/2013 01:40 AM, Anand Avati
wrote:<br>
</div>
<blockquote
cite="mid:CAFboF2wdkMJcoH-s0O432D0DoopqGGKbsPGqpm4qO-emGFJUaQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Fri, Feb 22, 2013 at 5:39 AM, Pranith
Kumar K <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
hi,<br>
Could you let us know where is this feature used. I mean
the use cases it addresses.<br>
</blockquote>
<div><br>
</div>
<div>Can you be more specific about the question? Not sure I
understand what you are trying to ask..</div>
<div><br>
</div>
<div>Avati </div>
</div>
</blockquote>
Avati,<br>
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.<br>
<br>
Ex: We can change replica old subvol-0 change log to be referred by
subvol-1.<br>
<br>
gluster --mode=script volume create r2 replica 2
pranithk-laptop:/home/gfs/r2_0 pranithk-laptop:/home/gfs/r2_1<br>
volume create: r2: success: please start the volume to access data<br>
gluster --mode=script volume start r2<br>
volume start: r2: success<br>
gluster --mode=script volume set r2 client-log-level DEBUG<br>
volume set: success<br>
gluster --mode=script volume set r2 brick-log-level DEBUG<br>
volume set: success<br>
mkdir: cannot create directory `/mnt/r2': File exists<br>
<br>
gluster volume add-brick r2 replica 3 pranithk-laptop:/home/gfs/r2_2<br>
volume add-brick: success<br>
<br>
gluster volume remove-brick r2 replica 2
pranithk-laptop:/home/gfs/r2_0<br>
Removing brick(s) can result in data loss. Do you want to Continue?
(y/n) y<br>
volume remove-brick commit force: success<br>
<br>
gluster volume info<br>
<br>
Volume Name: r2<br>
Type: Replicate<br>
Volume ID: 0e3eac61-5b99-455a-a0fc-818138d0ce1e<br>
Status: Started<br>
Number of Bricks: 1 x 2 = 2<br>
Transport-type: tcp<br>
Bricks:<br>
Brick1: pranithk-laptop:/home/gfs/r2_1<br>
Brick2: pranithk-laptop:/home/gfs/r2_2<br>
<br>
This can potentially change the direction of self-heal. I was not
able to find any documentation about this feature, except this
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://community.gluster.org/q/volume-type-changes-supported-in-3-3-0/">http://community.gluster.org/q/volume-type-changes-supported-in-3-3-0/</a>
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?<br>
<br>
Pranith.<br>
</body>
</html>