What are the file and file system size limitations for Red Hat Enterprise Linux?

Solution Verified - Updated -


  • Red Hat Enterprise Linux
  • Optional: Global File System version 2 (GFS2) (requires Red Hat Cluster Suite, not supported on a single server)
  • Optional: XFS
  • File system limitation


  • What are the file and file system size limitations for Red Hat Enterprise Linux?
  • Are GFS2 file systems over 25 TB supported?
  • Is it possible to use Ext3 for file systems 16TB and above on Red Hat Enterprise Linux?
  • I cannot create a 20TB file system in Ext4 or Ext3.
  • Is it possible to use Ext3 for a very large file system (16 TB and above)? If not, which file system is recommended for very large file systems?
  • What is the maximum file size supported within a file system?


This following information can be found in the File systems and storage limits section in our Red Hat Enterprise Linux versions comparison chart: Red Hat Enterprise Linux technology capabilities and limits .

Certified and [maximum] individual file size

File system RHEL 3 RHEL 4 RHEL 5 RHEL 6 RHEL 7 RHEL 8
Ext2/3 1TiB (3.0) 2TiB (3.5+) 2TiB 2TiB 2TiB 2TiB 2TiB
Ext4 n/a n/a 16TiB (5.6+)2 16TiB 16TiB 16TiB
GFS1 2TiB 16TiB [8EiB] 16TiB [8EiB] n/a n/a n/a
GFS21 n/a n/a 100TiB (5.3+) [8EiB] 100TiB [8EiB] 100TiB [8EiB] 100TiB [8EiB]
XFS3 n/a n/a 100TiB [8EiB] 100TiB [8EiB] 500TiB [8EiB] 8EiB

Certified and [maximum] file system size

File system RHEL 3 RHEL 4 RHEL 5 RHEL 6 RHEL 7 RHEL 8
Ext2/3 1TiB (3.0) 2TiB (3.5+) [8TiB] 8TiB 8TiB (5.0), 16TiB (5.1+)4 16TiB 16TiB 16TiB
Ext4 n/a n/a 16TiB [1EiB] (5.6+)2 16TiB [1EiB] 50TiB [1EiB] 50TiB [1EiB]
GFS 2TiB 16TiB [8EiB] 16TiB [8EiB] n/a n/a n/a
GFS21 n/a n/a 100TiB (5.3+) [8EiB] 100TiB [8EiB] 100TiB [8EiB] 100TiB [8EiB]
XFS3 n/a n/a 100TiB [16EiB] 300TiB [16EiB]5 500TiB [16EiB] 1PiB


Units are given in binary prefix:

  • TiB = Tebibyte = 240
  • PiB = Pebibyte = 250
  • EiB = Exbibyte = 260

Theoretical limits

The difference between certified and maximum limit is that certified indicates what the file system has been tested to versus what the theoretical maximums are within the code base.

For example, GFS2 is a 64-bit based file system and has a theoretical limit of 8EiB, but only file systems up to the size in the above table have actually been tested so that is what is certified.

Red Hat will investigate, troubleshoot, and file bugs as needed on larger file systems. Engineering will make a commercially reasonable effort to fix bugs stemming from usage of file systems above supported limits. We may rely on customers for testing of patches and confirmation of fixes before rolling them into an official errata. If we cannot test patches which may provide solutions to issues, possible release of related fixes will be delayed.


  1. The GFS2 file system is based on a 64-bit architecture, which can theoretically accommodate an 8 EiB file system. However, the current supported maximum size of a GFS2 file system is 100 TiB. Though we can create large file systems on GFS2, in Red Hat Enterprise Linux 5.4, the use of GFS2 as a single server file system (i.e. not in a clustered environment) is deprecated. For details, see https://access.redhat.com/articles/5892.

  2. The Ext4 file system was a Technology Preview in RHEL 5.3, 5.4, and 5.5. RHEL 5.6 introduced full support for Ext4 as documented in the Release Notes.

  3. The solution for large file systems is to use XFS. The XFS file system is specifically targeted at very large file systems (16 TiB and above). Before RHEL 7, XFS userland was not be available in the base RHEL channel on RHN, it was provided as a layered product. Although GFS also supports very large file systems, its use is limited to Red Hat Cluster Suite environments. The maximum offset for sparse files of XFS is 8 EiB.

  4. The maximum capacity of the Ext3 is currently 16TiB. This enhancement was originally included in Red Hat Enterprise Linux 5 as a Technology Preview, and fully supported from RHEL 5.1 onward. Prior to this change, the maximum capacity available in RHEL 5.0 was 8TiB.

  5. Red Hat Enterprise Linux 6.8 or newer is required for 300TiB XFS file system support on RHEL 6.x. The previous maximum supported XFS file system size in RHEL 6.7 and earlier was 100TiB.

  • RHEL 5.1 Release Notes

  • To create an Ext3 file system larger than 8 TiB, you might need to use the mkfs.ext3 utility with 4K blocks and the -F option:

    # mkfs.ext3 -F -b 4096 /dev/BiggerGroup/biggervol

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.



> but increases to a certified max of 16TB and a theoretical max of 8EB

> for both Red Hat Enterprise Linux 4 and 5.

How do you mean by "theoretical" max?

I heard that RHEL6 can handle over 16TB but e2fsprogs can't do now in fact.

You means "If I implement XFS or other file sysmtems by myself" so I can hadle over 16TB file system?

And Can redhat support it technically?


Hi,  The difference between 'certified' and 'limit' is that 'certified' indicates what the file system has been tested to versus what the theoretical 'limits' are within the code base


We have ext3 file system & would like create 4TB partition , can we have single file more than 3TB that will be generated by application/program over the one month.

Look at: http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-6-technology-capabilities-and-limits

You will see that ext3 is limited to 2TB for a single file. You will need to move to ext4 or XFS.

Thnak for update , I confirm 2TB for single file ext3 limit , we have RHEL 5.7 installed & we have single drive 5.7TB can we create 4TB or 5TB file system by command


meaning to say does ext4 file system supported by RHEL 5.7 ant KB


Yes, mkfs.ext4 can be used on disks or partitions up to 16TB for RHEL 5.4 and later.

link broken http://www.redhat.com/rhel/compare/

Please correct the unit names to their correct names:

"TB = Terabyte = 2^40
EB = Exabyte = 2^60"

As per units(7) http://man7.org/linux/man-pages/man7/units.7.html

       Prefix   Name   Value
              Ki       kibi   2^10  = 1024
              Mi       mebi   2^20 = 1048576
              Gi       gibi   2^30 = 1073741824
              Ti       tebi   2^40 = 1099511627776
              Pi       pebi   2^50 = 1125899906842624
              Ei       exbi   2^60 = 1152921504606846976

I am currently using ext4 , is there any option for extending beyond 16 TB..., we are getting below error ..

resize2fs: New size too large to be expressed in 32 bits

Have you found a solution for extending the FS beyond 16TB.? Even I am getting the same error.

The error talks about 32 bits. Are your running a 32 bit installation? What does the command "file $(which resize2fs)" output? If it shows it is 32 bit then you might be able to expand you install the 64 bit version (assuming your underlying RHEL is not 32 bit itself).

However, the discussion makes it clear that only 16TiB is supported on ext4 and sizes above that are "theorectical" but not "tested". It suggests going to XFS if you need larger than 16TiB.

Alternatively you could determine if you really need a single filesystem. We break up large Oracle databases onto multiple ext4 filesystems rather than putting them all in one.

I am running 64bit edition. When I try to resize the filesystem beyond 16TB getting the error. resize2fs: New size too large to be expressed in 32 bits. successfully extended the logical volume to 18 TB. but when I ran resize2fs on the LV getting the error.

XFS is supported up to 300 TB on RHEL 6.8 or above


Thanks for keeping this document updated. I last looked at it in 2014 and was happy to see it was updated at the end of 2017.

Note on the ext3 comments posted in 2014: ext3 was better than ext2 but with the advent of ext4 we found that converting filesystems from ext3 to ext4 made many operations quite a bit faster for large filesystems.. For large filesystems we had turned off automatic fsck because this could be excruciatingly slow booting a server relying on ext3. For ext4 even when running a "full" fsck it is much faster and allowed us to re-enable automatic check parameters.