Bug 171432 - Error formating 6985.9 GB partition (size from fdisk -l)
Error formating 6985.9 GB partition (size from fdisk -l)
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2005-10-21 13:57 EDT by Daniel Davidson
Modified: 2015-01-07 19:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.35-12.3.EL4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-09 16:05:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Davidson 2005-10-21 13:57:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I have a 6985.9 GB external scsi raid drive (shows as 1 disk to os) that when I go mke2fs /dev/sdb1 in RHEL4 update 2 will only show as 363G when I do a df -h.  The os sees this as ture and will only place 363G on drive (confirmed by trying to copy data to drive).  Similar results occurr in mkfs and mkfs.ext3 if I run those.

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

How reproducible:

Steps to Reproduce:
1.fdisk /dev/sdb
2.delete partitions
3.create single partion for entire disk
4.mke2fs /dev/sdb1
5.mount -t ext3 /dev/sdb1 /iscsi
6.df -h

Actual Results:  [root@server-backup ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             362G   15G  329G   5% /
/dev/sda1              99M   13M   81M  14% /boot
none                  3.9G     0  3.9G   0% /dev/shm
/dev/sdc1             193G  203M  183G   1% /var
/dev/sdb1             363G   20K  345G   1% /iscsi

Expected Results:  [root@server-backup ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             362G   15G  329G   5% /
/dev/sda1              99M   13M   81M  14% /boot
none                  3.9G     0  3.9G   0% /dev/shm
/dev/sdc1             193G  203M  183G   1% /var
/dev/sdb1             6.9T   20K  6.9T   0% /iscsi

Additional info:

Release notes from RHEL 4 Update 1 say this should work (ext3 support up to 8TB).  I originally had this connecting via a sanrad scsi/iscsi gateway, but that has been removed, it is now directly connected via scsi.
Comment 1 Stephen Tweedie 2005-10-21 14:27:35 EDT
What exactly does "fdisk -l /dev/sdb" show?  

U2 does support ext3 filesystems up to 8TB, but standard msdos partitioning is
still limited to 2TB, so I suspect that it's actually an fdisk limit, not a
filesystem one, that you are encountering.  fdisk -l output will help to
determine this.
Comment 2 Daniel Davidson 2005-10-21 14:38:59 EDT
Here you go.


[root@server-backup ~]# fdisk -l /dev/sdb
Note: sector size is 4096 (not 512)

Disk /dev/sdb: 6985.9 GB, 6985999319040 bytes
255 heads, 63 sectors/track, 106166 cylinders
Units = cylinders of 16065 * 4096 = 65802240 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      106166  2527259612   83  Linux
Comment 3 Thomas Woerner 2005-11-10 07:58:29 EST
Is this a x86_64 installation with e2fsprogs.x86_64?

Please provide the output of
1)  uname -a
2)  rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{arch}\n" e2fsprogs
Comment 4 Thomas Woerner 2006-08-01 10:57:22 EDT
Thers is an update package of e2fsprogs: e2fsprogs-1.35-12.3.EL4

This update package should solve your problem.
Comment 6 Eric Sandeen 2007-05-04 23:50:50 EDT
Daniel, can you confirm that e2fsprogs-1.35-12.3.EL4 fixed this problem?

Comment 7 Daniel Davidson 2007-05-09 15:53:49 EDT
I am unable to confirm as this machine no longer exists as specified in the
original inquiry.

Comment 8 Eric Sandeen 2007-05-09 16:05:50 EDT
Thanks Daniel.  Closing for now, not sure there's a lot more to be done here -
I'm going on the assumption that e2fsprogs-1.35-12.3.EL4 fixed it, as Thomas

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