There is already the Nimbus ExaDrive 100TB SSD and the 200TB SSD will come soon. As you can read here ext4 supports up to 256 TB. It's only a matter of time hardware will reach this limit.

Will they update ext4 or will there be ext5? What will happen?

  • 1
    No need for a large SSD and people have been using ext4 on petabyte arrays for years. Try truncate -s 2P some-file; mkfs.ext4 some-file to create a 2PiB large FS which works just fine. See wikipedia for filesystem limits. Commented Jan 7, 2023 at 20:16
  • 1
    @StéphaneChazelas Wikipedia indeed says the limit is 1EB. So is it wrong what he says in the link I mentioned (256TB)?
    – zomega
    Commented Jan 7, 2023 at 20:20
  • 14
    @zomega it’s outdated; 256TiB is the maximum size for a 32-bit ext4 file system. Commented Jan 7, 2023 at 22:12
  • 1
    this sparks a memory of hearing about, here on unix & linux, that the Linux OS (such as redhat) often has file system limitations which are different than the file system (EXT4, XFS, BTRFS) chosen. you may find this interesting - access.redhat.com/articles/rhel-limits
    – ron
    Commented Jan 9, 2023 at 16:57
  • ... unix.stackexchange.com/questions/712283/…
    – ron
    Commented Jan 9, 2023 at 18:18

4 Answers 4


64-bit ext4 file systems can be up to 64ZiB in size with 4KiB blocks, and up to 1YiB in size with 64KiB blocks, no need for an ext5 to handle large volumes. 1 YiB, one yobibyte, is 10248 bytes.

There are practical limits around 1 PiB and 1 EiB, but that’s still (slightly) larger than current SSDs, and the limits should be addressable within ext4, without requiring an ext5.

  • 3
    @marcelm, if you have a > 1 ZiB (or even more than a few PiB) storage device, chances are you'll want larger blocks than 4K anyway. Commented Jan 8, 2023 at 18:12
  • 4
    @StéphaneChazelas with the significant caveat that ext4 file systems with block sizes larger than 4KiB can’t be mounted on x86-64 systems. Commented Jan 8, 2023 at 19:54
  • 2
    @StephenKitt you mount it with FUSE though
    – phuclv
    Commented Jan 9, 2023 at 3:26
  • 1
    @phuclv what’s the performance like when you do that? Commented Jan 9, 2023 at 7:10
  • 1
    @ScottishTapWater not if you’re using ARM64 or POWER ;-). But yes, for most users it means the hard limit is 64 ZiB (which is still quite a lot more than the practical 1 EiB limit). Commented Jan 10, 2023 at 10:09

The 64bit ext4 filesystem feature removes the 232 block limit. If this feature was not enabled when your filesystem was created, you can add it to the superblock using tune2fs(8):

tune2fs -O 64bit /dev/sda1

This is a filesystem feature, not a mount option, so it must be specified either while creating the filesystem, or added later. From ext4(5):

         Enables the file system to be larger than 2^32 blocks.
         This feature is set automatically, as needed, but it can
         be useful to specify this feature explicitly if the file
         system might need to be resized larger than 2^32 blocks,
         even if it was smaller than that threshold when it was
         originally created.  Note that some older kernels and
         older versions of e2fsprogs will not support file systems
         with this ext4 feature enabled.

Any ext4 filesystem built with mke2fs since 2015 will have this feature enabled by default.

  • 3
    Indeed, thanks for explaining that. It’s perhaps worth adding that the 64-bit feature is enabled by default in most distributions nowadays (it became the default in e2fsprogsmke2fs.conf in May 2015), so file systems created within the last few years have it enabled. In any case, mke2fs will refuse to create a too-large file system if 64-bit is disabled. Commented Jan 9, 2023 at 8:02

While ext4 can in theory handle filesystems up to 2^64 * blocksize = 64ZiB in size (for commonly used 4KiB blocksize), on a more practical note there are implementation contstraints today at 2^48 * blocksize = 1EiB (@ 4KiB blocksize) due to the inode's 2^48-1 block address limit for the extent format currently in use. There start to be some performance issues above 1 PiB due to the current block allocator, though still pretty usable and we have many hundreds of ext4 filesystems around this size in production. The block allocator can probably be fixed in the code without any (major) on-disk format changes, and the extent format could also be extended once it becomes a real limitation.

  • Do you have a reference for that 1 EiB limit? I've changed the ext4 wikipedia page from 1EiB to 1YiB based on the kernel.org doc given by @StephenKitt, but maybe I shouldn't have? Commented Jan 9, 2023 at 6:15
  • 3
    Well, there's Files with extents must be placed within the first 2^48 blocks of a filesystem. It’s not clear what happens with larger filesystems. at kernel.org/doc/html/latest/filesystems/ext4/… Commented Jan 9, 2023 at 6:18
  • Right. The current extent format allows addressing block numbers up to 2^48-1, and block size is typically 2^12, so this limits the filesystem to 2^60-1 blocks ~= 1EiB. There is no other block allocation format for inodes today, so while you could have a 2^63-1 block filesystem, you couldn't use 7/8 of it.
    – LustreOne
    Commented Jan 10, 2023 at 23:09

Others have answered the question about large partitions, but I thought it would be helpful to answer the question about when ext5 is coming.

Ext4 is currently maintained by Theodore Ts'o. According to a 2009 Ars Technica article:

Despite the fact that Ext4 adds a number of compelling features to the filesystem, T'so doesn't see it as a major step forward. He dismisses it as a rehash of outdated "1970s technology" and describes it as a conservative short-term solution. He believes that the way forward is Oracle's open source Btrfs filesystem, which is designed to deliver significant improvements in scalability, reliability, and ease of management.

Of course this is far from a firm commitment to never implement a file system called ext5, but I believe there is little appetite for this right now.

  • 2
    2009 is quite a while ago, and a number of things have happened in the world of file systems. Has he said anything about filesystems in the future since? Commented Jan 10, 2023 at 12:39
  • I couldn't find anything more recent - hence my relatively non-commital answer. My guess would be Ts'o still sees ext4 as "1970s technology", and even if he doesn't endorse btrfs any more, he'd still endorse something that moves away from designs with ext4's heritage - which probably wouldn't be called ext5.
    – James_pic
    Commented Jan 10, 2023 at 14:46
  • I suspect the same, it was more what he now endorsed I was interested in. Commented Jan 10, 2023 at 14:56
  • Except that Ted is still actively maintaining ext4 and it is in use on billions of Android devices and cloud computers, so it isn't going away any time soon.
    – LustreOne
    Commented Jan 10, 2023 at 23:06
  • @LustreOne it's certainly true that ext4 is still actively maintained and widely used, but it sounds like you disagree with something and I'm not certain what that is.
    – James_pic
    Commented Jan 11, 2023 at 9:45

You must log in to answer this question.

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