How to Reduce the Size of an ext2, ext3 or ext4 Filesystem on Linux Systems

Objective

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

Background

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

1. Reduce the size of the filesystem by the required amount.
2. 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.

Scenario

Suppose that /dev/vg0/foo was originally an 120GB logical volume containing an ext3 filesystem. You wish to reduce its size to 80GB, making 40GB available for other purposes.

(The method described here is not specific to LVM, and could be usefully applied to any block device that can be resized without destroying its contents.)

Method

Overview

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

1. Ensure that you have an up to date backup.
2. Unmount the filesystem.
3. Check the filesystem.

(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:

umount /dev/vg0/foo

(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:

fsck -f /dev/vg0/foo

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:

resize2fs /dev/vg0/foo 80G

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:

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

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:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg0-foo   82569904    188292  78187308   1% /mnt

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:

dumpe2fs -h /dev/vg0/foo

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

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

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.