How to shrink a partition below the minimum size reported by resize2fs?

Question

I want to shrink a 250GB ext4 partition down to 200GB with resize2fs.

The df tool says the partition is about 40% filled up. So, I guess I can, at least, shrink the partition to that level.

Yet, when I try to shrink the partition with resize2fs, it fails. It says that the shrunk partition size is "smaller than minimum".

I think it’s because the partition still has traces of files that were previously deleted, so resize2fs thinks they’re still on the partition, and shrinking could mean losing those data, thus refusing to shrink the partition.

So my questions are:

• How can I make resize2fs realize the partition is indeed 60% empty, so that I can shrink it?
• Is there any way to reallocate used blocks, or something like that?

NOTE: I'm a moderately experienced Xubuntu user.

Solution

resize2fs doesn’t care about your deleted data. If it’s refusing to shrink your file system down to 200 GiB, it’s because it reckons it needs more room either to store the file system structure after the resize, or to perform the resize operation itself. You can see the details here (assuming you can read C); in summary:

• the file system needs enough room to store the required number of group descriptors, given the number of inodes;
• it needs enough room to store the data in the files;
• the resize operation needs extra inode tables for its background operations to ensure the resize will successfully complete;
• each inode group incurs some overhead, which must be accounted for (and can affect the way data is split across groups, requiring more groups and thus more overhead);
• space needs to be reserved to allow the extent tree to grow if necessary, and this can cause large amounts of overhead (especially when resizing, if there’s a lot of data in the part of the file system which needs to be cleared).

Some extra fudging overhead is added too (file system tools tend to play it very safe).

You can find out how small your file system can be made by running resize2fs -P. resize2fs -M will automatically make it as small as possible.

Comments

[LustreOne]

Note that you can run resize2fs multiple tones. It may be that initially the filesystem metadata may be consuming too much space, but after the resize some of the metadata will be released and you can shrink it further.

[SF.]

250GB ->200, 40% filled so there's 100GB of data, and 100GB of free space. Just HOW MUCH does resize2fs need if as much free space as present data is not enough?!

[telcoM]

It might be that some of the non-deleted files occupy the last 50 GB of the partition. Running e4defrag on the filesystem before attempting to shrink it might be helpful. And remember that an ext2/3/4 filesystem must be unmounted for shrinking!

[Stephen Kitt]

@telcoM resize2fs is capable of moving files around on its own.

[telcoM]

@StephenKitt Thanks, that's good to know. Then the problem must be something else: would files marked with an "immutable" attribute be considered as non-movable? Or it might be useful to unmount the filesystem and run a fsck on it, in case it has some minor corruption that makes resize2fs unhappy.

[Stephen Kitt]

@telcoM no, immutable files aren’t non-movable. Corruption would cause resize2fs to bail out and request a fsck. resize2fs -d 32 -M would give more information...

[helvete]

In my case this was the reason as well. Some proces (gitlab-runner) still accessing the FS I needed to unmount, although not shown with lsof. The error message complaining about FS size is really misleading.