Re: Resising underlying array

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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/





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux