When attempting to resize and old ext4 Partition that was created without the 64bit flag, resize2fs 1.42 will fail if the new size is or exceeds 16TiB.

$ resize2fs -p /dev/mapper/target-device
resize2fs: New size too large to be expressed in 32 bits

I do not want to copy the files to an external medium. I do not want to risk data loss either. How can i resize the volume safely?


3 Answers 3


With the option -O 64bit (enabled by default in filesystems created today), ext file systems can span 1024 PiB instead of just 16 TiB volumes. You can upgrade your old filesystem to activate this option.

Before you start

  1. This size of volume must be backed by RAID. Regular disk errors will cause harm otherwise.
  2. Still, RAID is not a backup. You must have your valuables stored elsewhere as well.
  3. First resize & verify all surrounding volumes (partition tables, encryption, lvm).
  4. After making changes to RAID, linux may not immediately acknowledge the new maximum size. Check $ cat /proc/partitions, reboot if necessary.
  5. Use a recent, supported kernel. If in doubt, install all upgrades and reboot.
  6. Acquire e2fsprogs of at version 1.43 (2016-05-17) or greater
  • ✔️ Ubuntu 20.04 (2020-04-23) ships with e2fsprogs 1.45.x (good!)
  • ✔️ Ubuntu 18.04 (2018-04-26) ships with e2fsprogs 1.44.x (good!)
  • Ubuntu 16.04 (2016-04-21) was released with e2fsprogs 1.42.12 (2014-08-25) - upgrade to a newer release or install a newer version manually (see end of this answer):

Steps for a disk at /dev/mapper/target-device

Step 1: Properly umount

$ sudo umount /dev/mapper/target-device

Step 2: Ensure consistency before starting

$ sudo e2fsck -fn /dev/mapper/target-device

-n flag means to not make changes. Depending on what caused the errors, letting e2fsck attempt repair may help.

Step 3: Enable 64bit support in the filesystem

$ sudo resize2fs -b /dev/mapper/target-device

Do consider reading man tune2fs and man resize2fs - you may wish to change some other filesystem flags as well. On a typical HDD RAID, this takes 4 minutes of high IO & CPU load.

Step 4: Resize

If you do not pass a size on the command line, resize2fs assumes "grow to all space available" - this is typically what you want.

$ sudo resize2fs -p /dev/mapper/target-device

On a typical HDD RAID, this takes 4 minutes of high IO & CPU load. The -p flag enables progress bars - but those only display after some initial steps.

Step 5: Check again

$ sudo e2fsck -fn /dev/mapper/target-device

e2fsck of newer versions may suggest to fix timestamps or extent trees. This is not an indication of any serious issue and you may chose to fix it now or later.

If errors occur, do not panic and do not attempt to write to the volume; consult someone with extensive knowledge of the filesystem, as further operations would likely destroy data!

If no errors occur, remount the device:

$ sudo mount /dev/mapper/target-device
$ df -h

Enjoy the new space!

If using ancient versions: Extra steps to enable source package support, download and compile a newer version of e2fsprogs on older systems:

$ resize2fs
# if this  prints version 1.43 or above, continue to step 1
$ sudo apt update
$ sudo apt install git
$ sudo apt build-dep e2fsprogs
$ cd $(mktemp -d)
$ git clone -b v1.44.2 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git e2fsprogs && cd e2fsprogs
$ ./configure
$ make
$ cd resize
$ ./resize2fs
# confirm that this prints 1.43 or higher
# use `./resize2fs` instead of `resize2fs` for the rest of the steps

You will not need any non-Ubuntu version of e2fsprogs for continued operation of the upgraded filesystem - the kernel supports those for quite some time now. It is only necessary to initiate the upgrade.

For reference, there is a similar error message mke2fs will print if it is asked to create a huge device with inappropriate options:

$ mke2fs -O ^64bit /dev/huge
mke2fs: Size of device (0x123456789 blocks) is too big to be expressed in 32 bits using a blocksize of 4096.
  • 1
    This is correct. I'd like to add that Redhat (thus RHEL, Centos, etc) used to prefer XFS over Ext4 in their installer when partitioning a filesystem over 16TB, and now just prefer XFS outright as the default filesystem.
    – Diablo-D3
    May 31, 2016 at 14:13
  • 2
    btrfs is not ready for production, and may never be ready for production, since Oracle has put development of it on the back burner. My personal opinion is if you need that level of file system complexity, use a tiny 8GB XFS root combined with using ZFS for your actual data storage needs.
    – Diablo-D3
    Jun 2, 2016 at 16:37
  • I did not work with "sudo e2fsck -fn" for me. I had to remove the -n flag.
    – Tigerware
    Jul 28, 2021 at 5:29
  • @BluE My guide mentions the -n option, because usually the filesystem should be clean. If its not and you cannot tell why, scaling up might not even be a good idea. Sure, e2fsck often is able to resolve filesystem inconsistencies for you - but how you want to handle such depends on what other options at verifying and recovering your data you have.
    – anx
    Jul 28, 2021 at 14:11

It happened to me recently, with an Ubuntu 18.04 that had been updated after being installed initially with a 16.04 Ubuntu ... The storage array (/dev/sdb) had been initially partitioned into two 14 TB partitions, and that's by wanting to enlarge the first partition to 28 TB that the problem occurred.

I did not need to download a new version of resize2fs because it was very recent.

# resize2fs 
resize2fs 1.44.1 (24-Mar-2018)

The only problem was to convert 64-bit partition 1 which had been formatted in 32 bits ... Instead of inviting the reader to consult the documentation of tune2fs (as Anx suggests), I propose a real example!

# tune2fs -O 64bit /dev/sdb1
tune2fs 1.44.1 (24-Mar-2018)
Please run "resize2fs -b /dev/sdb1" to enable 64-bit mode.

# resize2fs -b /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Convert the file system to 64 bits.
The file system on /dev/sdb1 now has a size of 3662109119 blocks (4k).

Finally, we enlarge the disk partition!

# resize2fs /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Resizing the file system on /dev/sdb1 to 7324303099 (4k) blocks.
The file system on / dev / sdb1 now has a size of 7324303099 blocks (4k).

If you cannot umount due to "busy filesystem", boot off LiveCD (Ubuntu Desktop). Use v18.04+ since it already has resize2fs v1.44.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .