12

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.

slm
  • 363,520
  • 117
  • 767
  • 871
heyo5388383
  • 121
  • 1
  • 1
  • 3
  • 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. – LustreOne Jul 18 '18 at 05:57

2 Answers2

11

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.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • 6
    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?! – SF. Jan 31 '20 at 10:21
  • 1
    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! – telcoM Jan 21 '21 at 09:28
  • 1
    @telcoM `resize2fs` is capable of moving files around on its own. – Stephen Kitt Jan 21 '21 at 09:33
  • @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. – telcoM Jan 21 '21 at 09:38
  • @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... – Stephen Kitt Jan 21 '21 at 09:42
0

In my case the problem was that the block device was in use but for some reason that was not reported, I unmounted the filesystem, and then turn off a libvirt-lxc virtual machine that used it and then it changed the error message and finally let me resize it

Israel
  • 11
  • 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. – helvete Mar 21 '22 at 13:29