mkfs.ext3 fails to create filesystem larger than 45GB
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:
Code:
#dumpe2fs /dev/sda11 | less |
Quote:
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. :scratch: 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. |
All times are GMT -5. The time now is 09:03 AM. |