<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
I'm preparing to upgrade my san to drbd9, but decided to test on
VM's first (smart idea).<br>
<br>
I've proceeded up to this point in the manual:<br>
<a class="moz-txt-link-freetext" href="http://drbd.linbit.com/users-guide-9.0/s-upgrading-drbd.html#s-upgrade-convert">http://drbd.linbit.com/users-guide-9.0/s-upgrading-drbd.html#s-upgrade-convert</a><br>
<br>
This talks about upgrading the meta-data:<br>
<blockquote type="cite">
<p>Now you need to convert the on-disk metadata to the new
version; this is really
easy, it’s just running one command and
acknowledging two questions.</p>
<p>If you want to change the number of nodes, you should already
have increased
the size of the lower level device, so that there is enough
space to store the
additional bitmaps; in that case, you’d run the command below
with an
additional argument <code class="literal">--max-peers=<span
class="emphasis"><em><N></em></span></code>. When
determining the number of
(possible) peers please take setups like the <a class="xref"
href="http://drbd.linbit.com/users-guide-9.0/s-drbd-client.html"
title="2.21. DRBD client">Section 2.21, “DRBD client”</a> into
account.</p>
</blockquote>
However, when I think, yes, that is a good idea, lets plan for the
future, and allow more peers, because I might want a 3rd copy of my
data, and/or I might use the DRBD "client". So I look in Section
2.21 which shows me how to prepare the config file, but I still need
to address the above problem "enough space to store the additional
bitmaps".<br>
<br>
Finally I find section 18.4 which references:<br>
<blockquote type="cite">
<p>In the quick-sync bitmap, one bit represents a 4-KiB chunk of
on-disk
data. If the bit is cleared, it means that the corresponding
block is
still in sync with the peer node. That implies that the block
has not
been written to since the time of disconnection. Conversely, if
the
bit is set, it means that the block has been modified and needs
to be
re-synchronized whenever the connection becomes available again.</p>
</blockquote>
So size of device divided by 4k divided by 8 should equal the size
of the bitmap in bytes, but I would assume there is some sort of
header or similar on this?<br>
<br>
<br>
So, I'm clearly missing something in the documentation, and my
google fu, plus RTFM isn't working.<br>
<br>
Can anyone advise the steps needed to "prepare" my LV which is
currently on-disk format v08 so that I can upgrade it to v09 with
additional sync nodes?<br>
<br>
ie, <br>
lvextend -L+xx /dev/vg0/drbdspace<br>
How to calculate xx ?<br>
<pre class="screen">drbdadm -v --max-peers=<N> create-md <resources></pre>
If the size of the device has changed, will drbdadm still "find" the
old v08 signature that it needs to update? I think the DRBD
signature is at the end of the device, but now the end of the device
has changed....<br>
<br>
Also, I wasn't able to find much (any) information on how to migrate
to drbdmanage. It almost seems like it would be a completely manual
process, managing the old style config files manually, creating the
new drbdmanage based device, then migrate the data from the old to
the new, etc... Ideally, there would be some automated solution to
import configs and devices/etc, and have drbdmanage do the
"conversion/migration" itself.<br>
<br>
Finally, just how "stable/reliable" is v9? How do you use it, what
issues have you seen? Is it faster/slower or more stable/less stable
etc than v8.4?<br>
<br>
Regards,<br>
Adam<br>
<div class="moz-signature">-- <br>
Adam Goryachev
Website Managers
<a class="moz-txt-link-abbreviated" href="http://www.websitemanagers.com.au">www.websitemanagers.com.au</a></div>
</body>
</html>