Bug 171432 - Error formating 6985.9 GB partition (size from fdisk -l)
Summary: Error formating 6985.9 GB partition (size from fdisk -l)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs
Version: 4.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Eric Sandeen
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-10-21 17:57 UTC by Daniel Davidson
Modified: 2015-01-08 00:11 UTC (History)
2 users (show)

Fixed In Version: 1.35-12.3.EL4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-09 20:05:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Daniel Davidson 2005-10-21 17:57:18 UTC
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):
e2fsprogs-1.35-12.2.EL4,util-linux-2.12a-16.EL4.12

How reproducible:
Always

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 18:27:35 UTC
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 18:38:59 UTC
Here you go.

Dan

[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 12:58:29 UTC
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 14:57:22 UTC
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-05 03:50:50 UTC
Daniel, can you confirm that e2fsprogs-1.35-12.3.EL4 fixed this problem?

Thanks,
-Eric

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

Dan

Comment 8 Eric Sandeen 2007-05-09 20:05:50 UTC
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
suggested.


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