Difference between revisions of "Shrink Logical Volume"

From LUG
Jump to navigation Jump to search
Line 1: Line 1:
 +
= Shrinking an LV =
 
Before you start - be aware that it is '''not''' currently possible to shrink xfs filesystems. Thus, if you need to shrink an XFS filesystem, your only option is to make a [[Add New Logical Volume|new LV]] that is smaller, copy the files from one to the other, then [[Remove Logical Volume|destroy]] the empty large LV.
 
Before you start - be aware that it is '''not''' currently possible to shrink xfs filesystems. Thus, if you need to shrink an XFS filesystem, your only option is to make a [[Add New Logical Volume|new LV]] that is smaller, copy the files from one to the other, then [[Remove Logical Volume|destroy]] the empty large LV.
  
Line 48: Line 49:
  
 
And remount.
 
And remount.
 +
 +
= Shrinking a PV =
 +
It is possible to shrink a Physical Volume by using <code>pvresize</code> to specify the size of the physical volume on the device, like so:
 +
 +
<code># pvresize --setphysicalvolumesize 40G /dev/sdb</code>
 +
<nowiki>  Physical volume "/dev/dm-10" changed
 +
  1 physical volume(s) resized / 0 physical volume(s) not resized</nowiki>
 +
 +
If there's not enough capacity available on the resized Physical Volume to contain the assigned Extents, then the command will fail, and you will have to shrink (or move) some LV's to make it fit. As above, try to shrink to about 90% of the intended size and then re-grow the PV back into the capacity once the underlying block device is resized - this allows you some wiggle room in case of a few megabytes of difference in expected size. Once this shrinking is done, then the underlying block device can be resized if it's coming in from a SAN, or the partition table can be edited to adjust the disk layout. Finish up with:
 +
 +
<code># pvresize /dev/sdb</code>
 +
<nowiki>  Physical volume "/dev/dm-10" changed
 +
  1 physical volume(s) resized / 0 physical volume(s) not resized</nowiki>
 +
 +
To use the newly available space.

Revision as of 14:47, 3 January 2018

Shrinking an LV

Before you start - be aware that it is not currently possible to shrink xfs filesystems. Thus, if you need to shrink an XFS filesystem, your only option is to make a new LV that is smaller, copy the files from one to the other, then destroy the empty large LV.

For ext4, however, it is possible to shrink a volume, but it cannot be done live, i.e. mounted.

First, note down the size of the filesystem when it's full. You won't be able to shrink it less than the maximum capacity without first removing files. # df -h

Filesystem                     Size  Used Avail Use% Mounted on
...
/dev/mapper/Vdata-Ldata         49G  4.6G   42G  10% /data

unmount the filesystem:

# umount /data

Then, perform a full e2fsck -f on the LV. This is required to allow resize2fs to be able to safely shrink the filesystem:

# e2fsck -f /dev/Vdata/Ldata

e2fsck 1.43.7 (16-Oct-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/Vdata/Ldata: 13473/3276800 files (1.6% non-contiguous), 1460799/13107200 blocks

If you encounter errors here, there may be problems with your underlying physical hardware. Next, you can resize the filesystem with resize2fs. You should aim to redice the filesystem to about 10% less than the final size, i.e. if you are reducing your LV to e.g. 30Gb from 50Gb, you should aim to reduce the filesystem to about 25Gb. You can bypass this calculation by using resize2fs -M /dev/Vdata/Ldata, but it will take significantly longer.

# resize2fs /dev/Vdata/Ldata 25G

resize2fs 1.43.7 (16-Oct-2017)
Resizing the filesystem on /dev/Vdata/Ldata to 6553600 (4k) blocks.
The filesystem on /dev/Vdata/Ldata is now 6553600 (4k) blocks long.

This will move all the data to the first sectors on the LV, and allow you to shrink it safely. This task is done with lvresize:

# lvresize /dev/Vdata/Ldata --size 30G

  WARNING: Reducing active logical volume to 30.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce Vdata/Ldata? [y/n]: y
  Size of logical volume Vdata/Ldata changed from 50.00 GiB (12800 extents) to 30.00 GiB (7680 extents).
  Logical volume Vdata/Ldata successfully resized.

Finally, re-increase the ext4 filesystem up to the new size:

# resize2fs /dev/Vdata/Ldata

resize2fs 1.43.7 (16-Oct-2017)
Resizing the filesystem on /dev/Vdata/Ldata to 7864320 (4k) blocks.
The filesystem on /dev/Vdata/Ldata is now 7864320 (4k) blocks long.

And remount.

Shrinking a PV

It is possible to shrink a Physical Volume by using pvresize to specify the size of the physical volume on the device, like so:

# pvresize --setphysicalvolumesize 40G /dev/sdb

  Physical volume "/dev/dm-10" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

If there's not enough capacity available on the resized Physical Volume to contain the assigned Extents, then the command will fail, and you will have to shrink (or move) some LV's to make it fit. As above, try to shrink to about 90% of the intended size and then re-grow the PV back into the capacity once the underlying block device is resized - this allows you some wiggle room in case of a few megabytes of difference in expected size. Once this shrinking is done, then the underlying block device can be resized if it's coming in from a SAN, or the partition table can be edited to adjust the disk layout. Finish up with:

# pvresize /dev/sdb

  Physical volume "/dev/dm-10" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

To use the newly available space.