Bug 139173 - can't create ext3 partition larger than 3TB
Summary: can't create ext3 partition larger than 3TB
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-13 16:55 UTC by Rudi Chiarito
Modified: 2007-11-30 22:10 UTC (History)
0 users

Clone Of:
Last Closed: 2005-09-09 15:23:41 UTC

Attachments (Terms of Use)

Description Rudi Chiarito 2004-11-13 16:55:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0

Description of problem:
Attempts to create an ext3 partition will result in its size to be
clipped to around 3TB, even if the underlying device is much larger.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Sell a kidney, half your liver and your neighbour's car to get more
than 3TB of storage
2. Run mkfs.ext3
3. See the filesystem size clipped to ~3TB

Actual Results:  # grep hdwr /var/log/messages
Nov 12 13:10:52 rome kernel: SCSI device sda: 23426646016 512-byte
hdwr sectors (11994443 MB)
# df -h /mnt/floppy/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda              2.9T  104M  2.9T   1% /mnt/floppy

Expected Results:  A >11TB filesystem. Or an error message. Or a warning.

Additional info:

According to

Filesystem block size:     1kB        2kB        4kB        8kB
File size limit:          16GB      256GB     2048GB     2048GB
Filesystem size limit:  2047GB     8192GB    16384GB    32768GB

Right now you need to run df after the system has taken its time to
create the new partition or you need to divine this kind of output
from mkfs.ext3:

# mkfs.ext3 -v -m1 -O sparse_super /dev/sda
mke2fs 1.35 (28-Feb-2004)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
max_blocks 4294967295, rsv_groups = 131072, rsv_gdb = 837
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
390430720 inodes, 780847104 blocks
7808471 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
23830 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616,
        102400000, 214990848, 512000000, 550731776, 644972544
Writing inode tables: done
inode.i_blocks = 147320, i_size = 4243456
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Although the maximum number of blocks is 4 billions, somehow mkfs
chooses to use 780 millions. It doesn't even ask for confirmation.

I doubt this would be any different if it were attempted on a LVM volume.

Yes, I know it's really not a good idea to create such a large
partition, but I was just testing the tools. And you can be sure that
it's only before a matter of time before storage this large becomes
relatively common.

I'll be able to test any fixes or workarounds only for a few more
days. After that, the hardware will be configured in a less extreme setup.

Comment 1 Thomas Woerner 2005-09-09 15:23:41 UTC
Fixed in FC3-updates in rpm e2fsprogs-1.38-0.FC3.1.

Note You need to log in before you can comment on or make changes to this bug.