Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, I'm preparing to upgrade my san to drbd9, but decided to test on VM's first (smart idea). I've proceeded up to this point in the manual: http://drbd.linbit.com/users-guide-9.0/s-upgrading-drbd.html#s-upgrade-convert This talks about upgrading the meta-data: > > 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. > > 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 |--max-peers=/<N>/|. When > determining the number of (possible) peers please take setups like the > Section 2.21, “DRBD client” > <http://drbd.linbit.com/users-guide-9.0/s-drbd-client.html> into account. > 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". Finally I find section 18.4 which references: > > 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. > 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? So, I'm clearly missing something in the documentation, and my google fu, plus RTFM isn't working. 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? ie, lvextend -L+xx /dev/vg0/drbdspace How to calculate xx ? drbdadm -v --max-peers=<N> create-md <resources> 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.... 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. 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? Regards, Adam -- Adam Goryachev Website Managers www.websitemanagers.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20160212/fcd1ce45/attachment.htm>