[DRBD-user] Offline Resize

Fri Dec 7 00:15:18 CET 2018

Not really clear to me but no we're not using an SSD.

(I'm not an expert on LVM so bear with me)
Are you saying that I would add some of the new PV to the existing LV so it
can be utilized and then perform a pvmove later?
If I'm using part of the new PV as part of the LV how would I ensure that
it's not overwritten when performing the pvmove later?

Here are my scenarios below maybe you can add what you're thinking into it
and it will make more sense to me.

Original Scenario:
DISK_1   2TB
pvcreate /dev/sdd
vgcreate vg01 /dev/sdd
lvcreate -n 01lv -l 100%FREE vg01
Device: /dev/vg01/01lv
# drbd setup
drbdadm create-md clusterdb
drbdadm up clusterdb
drbdadm primary --force clusterdb
mkfs.ext4 /dev/drbd0
mkdir /01
mount /dev/drbd0 /01

RESIZE (ONLINE) - really slow currently takes over 20hours for the
migration, final outcome is that we have only one Physical disk after the
move
DISK_2   3TB
pvcreate /dev/sde
vgextend vg01 /dev/sde
pvmove /dev/sdd /dev/sde
vgreduce vg01 /dev/sdd
pvremove /dev/sdd
lvextend -l +100%FREE /dev/vg01/01lv
drbdadm -- --assume-clean resize clusterdb
resize2fs /dev/drbd0

RESIZE (OFFLINE) - attempted so far
umount /u01
drbdadm down clusterdb
drbdadm dump-md clusterdb > /tmp/metadata
... receive error here, unable to move past

On Thu, Dec 6, 2018 at 4:47 PM Adam Goryachev <
mailinglists at websitemanagers.com.au> wrote:

> On 7/12/18 9:44 am, G C wrote:
>
> Correct we're adding a new physical device with larger capacity then using
> pvmove to relocate to new device, etc...
>
> The problem is that it takes a long time to complete the pvmove and it out
> of space on the original device (hence the move) we wouldn't be able to use
> the system until the migration was completed.
>
>
> I am pretty sure you could just allocate space from the new PV to the
> existing LV, that way, the LV will span both the old PV and the new PV. If
> you are using SSD storage, then this won't matter, if you are using
> spinning disks, then you might want to specifically allocate blocks from
> the new PV in the physical position where it will end up when finished, and
> then when you do the pvmove later, it will be contiguous with the old and
> new data all on the new PV.
>
> Does that make sense?
>
> Regards,
> Adam
>
>
>
> On Thu, Dec 6, 2018 at 4:35 PM Adam Goryachev <
> mailinglists at websitemanagers.com.au> wrote:
>
>> On 7/12/18 9:30 am, G C wrote:
>>
>> Thank you for your response.
>>
>> In our scenario we're limited to a single PV on the LVM and while online
>> does work it takes a long time for the pvmove to complete from say 2TB to a
>> 3TB PV.
>>
>> We're trying the offline in hopes that it would speed things up a lot.
>>
>> Sorry, I still don't understand. If you have a single PV, what are you
>> using pvmove for?
>>
>> In my scenario, I use lvextend and then drbdadm resize.
>>
>> Or do you mean you are adding additional physical devices with larger
>> capacity, and then using pvmove to relocate to the new device, and then
>> using lvextend to increase the size, and then drbdadm resize? and instead
>> you are planning to drbdadm down <resource> and then fiddle with the
>> underlying devices, and then drbdadm up ?
>>
>> Is the problem that pvmove takes a long time to complete, or that it
>> affects performance too much during the move? Just curious...
>>
>> Regards,
>> Adam
>>
>>
>>
>> On Thu, Dec 6, 2018 at 4:26 PM Adam Goryachev <
>> mailinglists at websitemanagers.com.au> wrote:
>>
>>>
>>> On 7/12/18 8:54 am, G C wrote:
>>>
>>> Version:
>>> drbd84-utils.x86_64     8.9.2-1.0.1.el7
>>>
>>> cat /proc/drbd
>>> version: 8.4.10 (api:1/proto:86-101)
>>> srcversion: 75EFA3DCEBEF5C771A0FCFC
>>>
>>> Following instructions located here for offline with internal metadata
>>> https://docs.linbit.com/docs/users-guide-8.4/#s-resizing
>>> I always get this error, I've found several issues that are similar but
>>> haven't found anyway to get past this issue.
>>> Architecture
>>> LVM > DRBD
>>>
>>> # drbdadm down <resource>
>>>>
>>>> # drbdadm dump-md clusterdb > /tmp/metadata
>>>>
>>>> Found meta data is "unclean", please apply-al first
>>>>
>>>> Command 'drbdmeta 0 v08 /dev/drbd/clusterdb internal dump-md'
>>>>> terminated with exit code 255
>>>>
>>>>
>>>
>>> Out of interest, why do you need to use offline resize? I always have
>>> used the online resize with no issues (LVM underneath). Simply increase the
>>> LV (on both nodes) and then issue a "drbdadm resize <resource>" command.
>>>
>>> Not sure if that helps, or if you have a reason for using offline
>>> resize, maybe someone else can assist with that.
>>>
>>> PS, using 8.4.x versions.
>>>
>>> Regards,
>>> Adam
>>>
>>> --
>>> Adam Goryachev Website Managers www.websitemanagers.com.au
>>>
>>> -- The information in this e-mail is confidential and may be legally
>>> privileged. It is intended solely for the addressee. Access to this e-mail
>>> by anyone else is unauthorised. If you are not the intended recipient, any
>>> disclosure, copying, distribution or any action taken or omitted to be
>>> taken in reliance on it, is prohibited and may be unlawful. If you have
>>> received this message in error, please notify us immediately. Please also
>>> destroy and delete the message from your computer. Viruses - Any
>>> loss/damage incurred by receiving this email is not the sender's
>>> responsibility.
>>> _______________________________________________
>>> drbd-user mailing list
>>> drbd-user at lists.linbit.com
>>> http://lists.linbit.com/mailman/listinfo/drbd-user
>>>
>>
>> --
>> Adam Goryachev Website Managers www.websitemanagers.com.au
>>
>> -- The information in this e-mail is confidential and may be legally
>> privileged. It is intended solely for the addressee. Access to this e-mail
>> by anyone else is unauthorised. If you are not the intended recipient, any
>> disclosure, copying, distribution or any action taken or omitted to be
>> taken in reliance on it, is prohibited and may be unlawful. If you have
>> received this message in error, please notify us immediately. Please also
>> destroy and delete the message from your computer. Viruses - Any
>> loss/damage incurred by receiving this email is not the sender's
>> responsibility.
>>
>
> --
> Adam Goryachev Website Managers www.websitemanagers.com.au
>
> -- The information in this e-mail is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this e-mail
> by anyone else is unauthorised. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful. If you have
> received this message in error, please notify us immediately. Please also
> destroy and delete the message from your computer. Viruses - Any
> loss/damage incurred by receiving this email is not the sender's
> responsibility.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20181206/e0fc8231/attachment.htm>