0

I currently have the following partitions:

  ACTIVE            '/dev/vg_server/lv_root' [50.00 GiB] inherit
  ACTIVE            '/dev/vg_server/lv_home' [1.76 TiB] inherit
  ACTIVE            '/dev/vg_server/lv_swap' [5.86 GiB] inherit

I would like to reduce the lv_home partition which is almost empty and increase the lv_root partion as it is getting close to full. I have a full backup but would like to do this on a live server which I do not have the ability to use a live CD on.

I would like to resize the partitions and reboot and get everything running again fairly quickly. Is there a moderately safe way to do this?

2 Answers 2

0

The basic problem is to avoid having to use your backups. If lv_home is really "almost empty",

  • you could shrink that (resize the filesystem, then shrink the logical volume), and
  • use the freed-up space for a temporary volume to copy lv_home to.
  • Then, the existing lv_home is empty, and you can demolish it, extend lv_root as needed, and
  • finally (if lv_home is really that small, initially), move the temporary volume's contents back into the part of the empty space that you don't need for lv_root, and combine that with the temporary space.

The suggested ordering assumes that the underlying disk partitions are in the same order, of course. LVM is not suited to shifting partitions up and down (as some offline disk partitioning tools may do).

Now - the OP's question did not mention whether the underlying filesystem(s) all reside on one physical disk, and whether their disk partitions are in the same order. If they all reside on one physical disk, the question comes up whether this is partitioned with MBR (a maximum of four physical partitions) or GPT (128) -- see for example What's the difference between MBR and GPT? . In the former case, OP may have to create an extended partition as a basis for the resized lv_home partition.

LVM is essentially three layers: physical, volumes and logical. To keep things tidy, it's nice to have the physical disks adjacent. But LVM does not require that. One could shrink lv_home (and its filesystem and physical partition) in one step, and then create a new physical partition in the space on the end, adding that partition to the volume group corresponding to lv_root and then running resize2fs to extend the filesystem. Resizing up has a lot of existing practice; going down far less so -- until recently the documentation had caveats explaining that you could trash your filesystem with the tool.

These may be helpful:

2
  • Thanks and good ideas. In my case lv_home is 99% empty, 1.7TB free.
    – Uberswe
    Sep 30, 2015 at 22:52
  • This method worked for me and it seems to be the safest way from what I can read. This answer was also very detailed and took into account other possible situations that may arise.
    – Uberswe
    Oct 3, 2015 at 18:46
0

Using lvextended command for change size of logical volume:

lvextend -l +4607 /dev/vg_home/LogVol01
resize2fs /dev/vg_home/LogVol01

I suggest reading up conceptually about lvm resize and reduce on this site.

3
  • OP seemed to already be aware of the basic tools. The real problem seems to be how to move the starting point of lv_home to make room for extending lv_root. Oct 1, 2015 at 9:30
  • Thomas we can easy do it lvextend can reduce with - and extended it with + Oct 1, 2015 at 9:39
  • My goal is to keep all the data on all partitions after the resize is done. How does this method compare to the answer @ThomasDickey wrote in terms of possibly overwriting files on the partition I would be shrinking?
    – Uberswe
    Oct 2, 2015 at 6:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .