Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== LVM - Reduce the size of an ext2, ext3 or ext4 filesystem ======

To reduce the size of an ext2, ext3 or ext4 filesystem

Reducing the capacity of a filesystem on a resizeable block device (such as a partition or logical volume) is a two-step process:

  - Reduce the size of the filesystem by the required amount.
  - Reduce the size of the underlying block device to match that of the filesystem.

The method for the first step depends on the type of filesystem, and the method for the second step depends on the type of block device.  These instructions cover step 1 in the case where the filesystem is ext2, ext3 or ext4.

It is very important that the steps above are carried out in the correct order.  Shrinking the block device without first shrinking the filesystem will probably destroy the filesystem.

**NOTE**:  The method described here is not specific to LVM, and could be usefully applied to any block device that can be re-sized without destroying its contents.

Resizing is performed using the **resize2fs** command, however there are some preparatory steps that you should or must take beforehand:

  * Ensure that you have an up to date backup.
  * Unmount the filesystem.
  * Check the filesystem.

**NOTE**:  In older documentation you may encounter references to the program **ext2resize**.  This is now obsolete and should not normally be used.

===== Ensure that you have an up to date backup of the filesystem =====

Shrinking a filesystem is a moderately high-risk operation, so if you take backups of the data at all then this is a good time to perform one.

===== Unmount the filesystem =====

If the filesystem that you wish to shrink is mounted then you will need to unmount it before proceeding further:

<code bash>
umount /dev/vg01/foo
</code>

**NOTE**:  At the time of writing it was possible to extend an ext3 or ext4 filesystem while mounted, but not to shrink it.  An ext2 filesystem could be neither extended nor shrunk while mounted when using a current (2.6-series) kernel.

===== Check the filesystem =====

One factor that would increase the risk of failure is if there are pre-existing errors in the filesystem.  This risk can be reduced by checking the filesystem before resizing it:

<code bash>
fsck -f /dev/vg01/foo
</code>

**resize2fs** will refuse to run if it thinks the filesystem ought to be checked first, however there is no harm in running fsck regardless provided that you are confident the filesystem is not mounted.

Do not check the filesystem until after you have unmounted it, otherwise fsck may itself cause data loss.

===== Resize the filesystem =====

Use the **resize2fs** command to resize the filesystem:

<code bash>
resize2fs /dev/vg01/foo 80G
</code>

You must specify the required final size of the filesystem when shrinking it.  The suffixes K, M and G may be used to specify a size in kilobytes, megabytes or gigabytes.  These are interpreted as traditional (binary) units, so 1G=1024M, 1M=1024K and 1K=1024 bytes.

The amount of time taken will depend on how much of the content needs to be relocated.  The filesystems considered here tend to disperse data throughout the underlying block device, so a large amount of copying may be needed even if the filesystem has never been filled beyond the size it is being reduced to.  Do not start resize2fs unless you are confident you can allow it to finish.  You can request a progress bar using the -p option.

When resize2fs has finished it should report the new size of the filesystem in blocks:

<code>
The filesystem on /dev/vg0/foo is now 20971520 blocks long.
</code>

Note that resize2fs does not change the block size, even if a freshly created filesystem on the same device would default to a smaller size.

===== Testing =====

You can obtain an approximate value for the new size of the filesystem using the **df** command once it has been remounted.  The output should be similar to the following:

<code>
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg01-foo   82569904    188292  78187308   1% /mnt
</code>

The number of 1k blocks reported (82569904 in this case) is slightly less than the full size of the device (83886080).  This is normal.  If you want to see the exact size, or do not want to mount the filesystem, then you can use the **dumpe2fs** command:

<code bash>
dumpe2fs -h /dev/vg01/foo
</code>

The output is quite lengthy, but should contain the following information:

<code>
Inode count:              5242880
Block count:              20971520
Reserved block count:     1048576
Free blocks:              20595403
Free inodes:              5242869
First block:              0
Block size:               4096
Fragment size:            4096
</code>

The block count should be the same as the value reported by **resize2fs**.  The size in bytes is the block count multiplied by the block size.

===== See also =====

  * [[LVM:Reduce the size of an LVM logical volume|Reduce the size of an LVM logical volume]]
  * [[LVM:Increase the size of an ext2, ext3 or ext4 filesystem|Increase the size of an ext2, ext3 or ext4 filesystem]]