[linux-lvm] Resising underlying array

[linux-lvm] Resising underlying array

[georges.giralt]

Hello 
I've an old server which use software raid and lvm (Debian based). 
It is made on a set of 3 320 GB Sata disks. 
The system is build on a couple of software mirror (3 legged): md0 is at start of disk, 200 MB size, used for /boot.
md1 is made with the remainder of the disk space and is set up as a 3 legged mirror which is the sole pv of the volume group onto which the system is built.
200 MB for /boot was sensible years ago but now is a joke. So I plan to extend these 3 partitions up to a couple of GB. And of course reduce by the same amount the 3 remaining partitions making md1.
The volume group is far from using all PE in the PV, so I hope I will be able to reduce the PV size without harm. But I'm unable to decide on a workflow and loosing data or downtime are not acceptable options... 
So I'm begging your help on a suitable workflow to make this happen.
Many thanks in advance ! 
P.S. the 3 disk are here from a time when the system was set up using mirroring into the LVM... Time long gone. 

Re: [linux-lvm] Resising underlying array

[matthew patton]

> 200 MB for /boot was sensible years ago but now is a joke.

since when? All you need is 2 kernels. Have Linux 3.x kernels gotten out of hand? I only use RHEL/Centos5 and 6 and I've never even come close to running out.

> reduce the PV size without harm. But I'm unable to decide on a workflow and�

> loosing data or downtime are not acceptable options...�

then don't bother.

> So I'm begging your help on a suitable workflow to make this happen.


A. tell the customer "too bad" buy newer/bigger hard drives already and build new layout on new disks and DD/RSYNC data to new layout

Or if you like to play with fire:
* reduce filesystem size
* lvresize down to match
* resize MD member device (eg.�http://webapp5.rrz.uni-hamburg.de/SuSe-Dokumentation/manual/sles-manuals_en/manual/raidresize.html)
* create partition out of newly available slack space (use kpartx and you should avoid a reboot)
* pvcreate on new partition, add to VG and grow LV into new space
* resize filesystem

Re: [linux-lvm] Resising underlying array

[matthew patton]

A nifty tool that got mentioned on the bcache mailing list.

https://github.com/g2p/blocks

Re: [linux-lvm] Resising underlying array

[Georges Giralt]

Le 03/07/2013 20:54, matthew patton a �crit :
>
>> 200 MB for /boot was sensible years ago but now is a joke.
> since when? All you need is 2 kernels. Have Linux 3.x kernels gotten out of hand? I only use RHEL/Centos5 and 6 and I've never even come close to running out.
>
>> reduce the PV size without harm. But I'm unable to decide on a workflow and
>> loosing data or downtime are not acceptable options...
> then don't bother.
>
>> So I'm begging your help on a suitable workflow to make this happen.
>
> A. tell the customer "too bad" buy newer/bigger hard drives already and build new layout on new disks and DD/RSYNC data to new layout
>
> Or if you like to play with fire:
> * reduce filesystem size
> * lvresize down to match
> * resize MD member device (eg. http://webapp5.rrz.uni-hamburg.de/SuSe-Dokumentation/manual/sles-manuals_en/manual/raidresize.html)
> * create partition out of newly available slack space (use kpartx and you should avoid a reboot)
> * pvcreate on new partition, add to VG and grow LV into new space
> * resize filesystem
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
Hello Matthew,
Actually my volume group has a big lot of free PE. (the 320 Gb disk are 
only used for the OS and a couple of administrative accounts for the 
server, so even the /home is small.... )
So I think I could avoid the resizing of the file systems.... All data 
is stored elsewhere.
This is why I thought I could do it online without too much risk. Of 
course I will not do this on Friday ;-)

-- 
If the only tool you have is a hammer, you tend to see every problem as a nail.
                 Abraham Maslow
A British variant :
Any tool can serve as a hammer but a screwdriver makes the best chisel.

Re: [linux-lvm] Resising underlying array

[Bryn M. Reeves]

On 07/03/2013 07:54 PM, matthew patton wrote:
>> 200 MB for /boot was sensible years ago but now is a joke.
> 
> since when? All you need is 2 kernels. Have Linux 3.x kernels gotten
> out of hand? I only use RHEL/Centos5 and 6 and I've never even come
> close to running out.

It partly depends on the distro and features you use - e.g. Fedora has
preupgrade which uses /boot as temporary storage. This requires
considerably more space than was required in the past (if you are going
to use the feature - otherwise, carry on regardless :).

Regards,
Bryn.

Re: [linux-lvm] Resising underlying array

[Georges Giralt]

Hello !
Today was a terrible day at work. So I did not touch my array nor LVM.
But I thought about it.
As I will resize the first disk partition, I'll touch the beginning of 
the PV (which is built on the mirror made of the second disk partitions).
So I wonder if LVM is "dumb" and won't notice that the first blocks are 
not the old first blocks (provided that the underlying array is synced), 
or if the LVM layer will loudly complain because the former blocks of 
the beginning of the PV have moved (Am I right or wrong here ??) ???
I've to admit that I'm reluctant to touch this server, given the day I 
had today...
So I beg, another time, for your advice.
Thanks for your help !
Le 04/07/2013 10:54, Bryn M. Reeves a �crit :
> On 07/03/2013 07:54 PM, matthew patton wrote:
>>> 200 MB for /boot was sensible years ago but now is a joke.
>> since when? All you need is 2 kernels. Have Linux 3.x kernels gotten
>> out of hand? I only use RHEL/Centos5 and 6 and I've never even come
>> close to running out.
> It partly depends on the distro and features you use - e.g. Fedora has
> preupgrade which uses /boot as temporary storage. This requires
> considerably more space than was required in the past (if you are going
> to use the feature - otherwise, carry on regardless :).
>
> Regards,
> Bryn.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

-- 
If the only tool you have is a hammer, you tend to see every problem as a nail.
                 Abraham Maslow
A British variant :
Any tool can serve as a hammer but a screwdriver makes the best chisel.