17

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?

zomega
  • 972
  • 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. – Stéphane Chazelas Jan 07 '23 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 Jan 07 '23 at 20:20
  • 14
    @zomega it’s outdated; 256TiB is the maximum size for a 32-bit ext4 file system. – Stephen Kitt Jan 07 '23 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 - https://access.redhat.com/articles/rhel-limits – ron Jan 09 '23 at 16:57
  • ... https://unix.stackexchange.com/questions/712283/file-system-choice-pitfalls-on-100tb-volume – ron Jan 09 '23 at 18:18
  • @ron the key difference there being “tested and supported” v. “theoretical”. – Stephen Kitt Jan 10 '23 at 10:13

4 Answers4

51

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.

Stephen Kitt
  • 434,908
22

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

  64bit
         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.

forest
  • 2,655
  • 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. – Stephen Kitt Jan 09 '23 at 08:02
10

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.

LustreOne
  • 1,774
  • 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? – Stéphane Chazelas Jan 09 '23 at 06: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 https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html#blocks – Stéphane Chazelas Jan 09 '23 at 06: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 Jan 10 '23 at 23:09
4

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.

James_pic
  • 151
  • 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? – Henrik supports the community Jan 10 '23 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 Jan 10 '23 at 14:46
  • I suspect the same, it was more what he now endorsed I was interested in. – Henrik supports the community Jan 10 '23 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 Jan 10 '23 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 Jan 11 '23 at 09:45
  • Are SSD's 1970s technology? In any case, it doesn't seem like much fun doing backups and restores to 100TB devices. – Jeremy Boden Jan 11 '23 at 23:40
  • I put "1970s technology" in quotes because it's a quote. That's Ts'o's phrasing, not mine. That's his own description of the thing he's maintaining. – James_pic Jan 12 '23 at 09:31