Hi,

We run some old Dell servers with RHEL 3ES and I've been running into what I believe is a limitation on ext3 filesystem size on extended logical partitions.

One of our disk have partition table as follows. I've just created a 70GB parition on sda11...

# fdisk /dev/sda

The number of cylinders for this disk is set to 17834.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 146.6 GB, 146695782400 bytes
255 heads, 63 sectors/track, 17834 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 3837 30716280 83 Linux
/dev/sda3 3838 4092 2048287+ 83 Linux
/dev/sda4 4093 17834 110382615 f Win95 Ext'd (LBA)
/dev/sda5 4093 6004 15358108+ 83 Linux
/dev/sda6 6005 7024 8193118+ 83 Linux
/dev/sda7 7025 7279 2048256 82 Linux swap
/dev/sda8 7280 7534 2048256 82 Linux swap
/dev/sda9 7535 7789 2048256 82 Linux swap
/dev/sda10 7790 7916 1020096 83 Linux
/dev/sda11 7917 16792 71296438+ 83 Linux

Command (m for help):

However, when attempting to mkfs.ext3 on sda11 I get only a 45GB filesystem size...

# mkfs.ext3 /dev/sda11
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
6111232 inodes, 12209392 blocks
610469 blocks (5.00%) reserved for the super user
First data block=0
373 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, 2654208,
4096000, 7962624, 11239424

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# df -k /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda11 48070472 32828 45595768 1% /mnt

I know fdisk reports 1K blocks since / filesystem (sda3) shows...
# df -k /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 2016044 499180 1414452 27% /

This matches the block size of sda3 in fdisk.

Have I stumbled on a ext3 filesystem limit issue in RHEL 3ES?

Any comments appreciated...

Regards,
Bobby

See if dumpe2fs agrees with what df reports:

Hi Blackhole54,

Here's dumpe2fs output:

Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 6d870440-14b3-4576-a4ea-51d318db080a
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6111232
Block count: 12209392
Reserved block count: 610469
Free blocks: 12009411
Free inodes: 6111221
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Thu Sep 6 11:33:24 2007
Last mount time: Thu Sep 6 11:34:07 2007
Last write time: Thu Sep 6 11:34:07 2007
Mount count: 1
Maximum mount count: 29
Last checked: Thu Sep 6 11:33:24 2007
Check interval: 15552000 (6 months)
Next check after: Tue Mar 4 12:33:24 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 8
Journal device: 0x0000
First orphan inode: 0
...
...

Looks like dumpe2fs also reports a filesystem size approx 50GB...
50009669632 = 12209392 * 4096

Cheers,
Bobby

Have you tried to resize it ???

According to this FAQ, ext3 should be able to handle filesystems in the terabyte range. If syg00's suggestion of resizing (I presume using resize2fs) doesn't work, you could, as an act of desperation, see if creating the filesystem specifying largefile or largefile4 worked better. Realize that his will increase the number of blocks per inode and so may no suite your needs.

BTW, TMK, before using resize2fs, you need to convert the filesystem to ext2 first, using tune2fs. You can convert it back afterwards. Syg00, do know if this is still a requirement?

Not a requirement - on 2.6. In fact for enlarging, doesn't even need to be unmounted.
Can't say for 2.4

Hi syg00, blackhole54,

Tried both largefile and largefile4 options to mke2fs with no success.

I created an ext2 filesystem on the partition, and got the following error from a resize2fs:

# resize2fs /dev/sda11 18000000
resize2fs 1.32 (09-Nov-2002)
The containing partition (or device) is only 12209392 blocks.
You requested a new size of 18000000 blocks.

12209392 blocks matched the value reported from dump2fs. Which seems to back my earlier suspicion that ext2/3 may not support/recognize filesystems larger than 45GB on extended logical partitions.

Also, I was able to create two 35GB filesystems when the available disk space was split into two partitions.

Cheers,
Bobby

Do the resize without a size - it'll fill the partition by default.

Below link shows that this is not a limitation on OS :

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

I believe this is something else. Run a strace on the mkfs.ext3 command :

#strace -xvfto -s 1000 mkfs.strace yourcommand

Check the file and see if that shed some light.

I happened to run into the same problem tonight...

My solution was to use Gparted (QTparted wouldn't do the job) to format the partition (in my case a 120GB partition on /dev/sdb) and everything worked fine.

Funny, I usually prefer command line tools, but this time the graphical interface worked better...

if you can, get RHEL4. and if you can recreate your FS - use LVM2
instead for the partitions. you'll find it easier to manage disk
allocations.