<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">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">
<pre>*Re-formatting*
</pre>
Hi,
<br>
<br>
In a cluster of 5 nodes a volumes V1 is present, which hosts 4
bricks on
<br>
nodes 1 through 4
<br>
<br>
N1 N2 N3 N4 N5
<br>
------ ------ ------ ------ ------
<br>
V1 N1 N2 N3 N4 X
<br>
<br>
Now a Snapshot is taken S1 and snap volfiles will be created on
nodes
<br>
<br>
N1 N2 N3 N4 N5
<br>
------ ------ ------ ------ ------
<br>
S1 S1VOL S1VOL S1VOL S1VOL S1VOL
<br>
<br>
At this point N5 goes down, and after that we issue a delete on
S1. The
<br>
delete will be successful, and will not log any missed entries
because
<br>
all nodes hosting snap bricks are up and we delete the snap
volfiles in
<br>
those nodes
<br>
<br>
N1 N2 N3 N4 N5
<br>
------ ------ ------ ------ ------
<br>
S1 X X X X X
<br>
<br>
At this point we create another snap with the name S1, but it
will be a
<br>
different snap with a different snap-uuid
<br>
<br>
N1 N2 N3 N4 N5
<br>
------ ------ ------ ------ ------
<br>
S1 S1VOL S1VOL S1VOL S1VOL S1VOL(old)
<br>
<br>
At this point N5 node comes up, and during handshake it receives
S1 snap
<br>
volume details from other node, which are for a different
snap(have
<br>
different snap-id).
<br>
<br>
The challenge is to make the node aware of the right snap vol,
without
<br>
resorting to a peer reject. This scenario will occur only with a
node,
<br>
that is not hosting a snap-brick for the said snapshot because
the
<br>
missed_snap_list keeps track of the missed creates, deletes and
<br>
restores, and will handle if any brick misses any of these ops.
<br>
<br>
What I propose is for the node to check if the incoming new Snap
ID
<br>
features in the missed snap-deletes list for the node it's
handshaking
<br>
with. If so, then its a no-op. If not, it should check, if any
<br>
snap-bricks for the said snap-volume are hosted in the peer,
that it's
<br>
handshaking with. If no, then again it will be a no-op. Only in
a case
<br>
where the node it is handshaking with, has no missed
snap-deletes for
<br>
the particular snap-id and is hosting a brick for the same, is
when it
<br>
will take precendence over the current node(N5). and the S1VOL
files
<br>
will be overwriten.
<br>
<br>
So the flowchart for any peer having a name conflict during
handshake
<br>
will be.
<br>
<br>
Step 1: Am I hosting any snap-bricks for the conflicted snap. If
yes
<br>
goto step 5
<br>
<br>
Step 2: Is the node I am handshaking with, has any missed
deletes for
<br>
the same snap-id. If yes then goto step 5
<br>
<br>
Step 3: Is the node I am handshaking with, hosting any
snap-bricks for
<br>
the conflicted snap, If no, then goto step 5
<br>
<br>
Step 4: The other node takes precedence, and I should delte my
snap-vol
<br>
files. Move on to the next snap
<br>
<br>
Step 5. It's a no-op. Move on to the next snap.
<br>
<br>
Regards,
<br>
Avra
<br>
</div>
<br>
On 04/10/2014 07:52 PM, Avra Sengupta wrote:<br>
</div>
<blockquote cite="mid:5346A936.1030406@redhat.com" type="cite">Hi,
<br>
<br>
In a cluster of 5 nodes a volumes V1 is present, which hosts 4
bricks on nodes 1 through 4
<br>
<br>
N1 N2 N3
N4 N5
<br>
--------- ----------- --------
------------ ---------
<br>
V1 B1 B2 B3
B4 X
<br>
<br>
Now a Snapshot is taken S1 and snap volfiles will be created on
nodes
<br>
<br>
N1 N2 N3
N4 N5
<br>
--------- ----------- --------
------------ ---------
<br>
S1 S1VOL S1VOL S1VOL S1VOL S1VOL
<br>
<br>
At this point N5 goes down, and after that we issue a delete on
S1. The delete will be successful, and will not log any missed
entries because all nodes hosting snap bricks are up and we delete
the snap volfiles in those nodes
<br>
<br>
N1 N2 N3
N4 N5
<br>
--------- ----------- --------
------------ ---------
<br>
S1 X X X
X S1VOL
<br>
<br>
At this point we create another snap with the name S1, but it will
be a different snap with a different snap-uuid
<br>
<br>
N1 N2 N3
N4 N5
<br>
--------- ----------- --------
------------ ---------
<br>
S1 S1VOL S1VOL S1VOL S1VOL
S1VOL(old)
<br>
<br>
At this point N5 node comes up, and during handshake it receives
S1 snap volume details from other node, which are for a different
snap(have different snap-id).
<br>
<br>
The challenge is to make the node aware of the right snap vol,
without resorting to a peer reject. This scenario will occur only
with a node, that is not hosting a snap-brick for the said
snapshot because the missed_snap_list keeps track of the missed
creates, deletes and restores, and will handle if any brick misses
any of these ops.
<br>
<br>
What I propose is for the node to check if the incoming new Snap
ID features in the missed snap-deletes list for the node it's
handshaking with. If so, then its a no-op. If not, it should
check, if any snap-bricks for the said snap-volume are hosted in
the peer, that it's handshaking with. If no, then again it will be
a no-op. Only in a case where the node it is handshaking with, has
no missed snap-deletes for the particular snap-id and is hosting a
brick for the same, is when it will take precendence over the
current node(N5). and the S1VOL files will be overwriten.
<br>
<br>
<br>
So the flowchart for any peer having a name conflict during
handshake will be.
<br>
<br>
Step 1: Am I hosting any snap-bricks for the conflicted snap. If
yes goto step 5
<br>
<br>
Step 2: Is the node I am handshaking with, has any missed deletes
for the same snap-id. If yes then goto step 5
<br>
<br>
Step 3: Is the node I am handshaking with, hosting any snap-bricks
for the conflicted snap, If no, then goto step 5
<br>
<br>
Step 4: The other node takes precedence, and I should delte my
snap-vol files. Move on to the next snap
<br>
<br>
Step 5. It's a no-op. Move on to the next snap.
<br>
<br>
Regards,
<br>
Avra
<br>
<br>
_______________________________________________
<br>
Gluster-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a>
<br>
</blockquote>
<br>
</body>
</html>