[DRBD-user] Offline Resize

[Adam Goryachev]

On 7/12/18 10:15 am, G C wrote:
> 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
>
For me, it is like this (simple case with SSD's)
pvcreate /dev/sde
vgextend vg01 /dev/sde
lvextend -L+900G /dev/vg01/01lv
drbdadm resize clusterdb

A somewhat simple solution to do what you want might be this (untested, 
so check it on a VM or test env first):
pvcreate /dev/sde
vgextend vg01 /dev/sde
lvcreate -n temp -l <xxx> vg01

Note, the size xxx is exactly equal to the size of 01lv which you can 
check with lvdisplay. This will allocate the first part of sde to a new 
LV called temp, it is just here to use up the space.

lvextend -l+100%FREE /dev/vg01/01lv

Note, I don't usually use this 100%FREE method, but I assume it will 
work right...

drbdadm resize clusterdb

This effectively means your LV 01lv is split across sdd and sde, which 
might improve performance, but increases risk if either disk dies.

At any time, you can now lvremove /dev/vg01/temp and can then do your 
pvmove which will move the first 2TB of 01lv from sdd to the beginning 
of sde.

There is a more complicated method, but this is what I would do if faced 
with your problem. I've also successfully used this script:
https://bisqwit.iki.fi/source/lvm2defrag.html

Which can assist you to ensure that the entire disk ends up contiguous 
(though you would need to have at least some temporary space, so better 
not to allocate 100% of the space in the step after you create the temp LV).

Also, why do you allocate 100% of the space? Why not leave some space 
for snapshots, or for future growth? If you had left 100G spare, then 
right now you would simply lvextend to use up the last 100G, and then 
have some time to deal with arranging the upgrade. Just my suggestions, 
but I don't understand your needs.

Regards,
Adam


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20181207/36827455/attachment-0001.htm>