ext3 + fs > 2Tbyte

Vincent McIntyre Vince.McIntyre at atnf.csiro.au
Mon Oct 31 08:33:43 UTC 2005

Hi list

this is actually a problem on a debian system but I thought you might
be interested to hear of it and perhaps can offer some help.

I have a woody box (dell pe750, dual cpu) running a kernel from 
backports.org (debian 'testing' packages built on a 'stable' box).
The kernel version is 2.6.7-1.backports.org.1.
This host is hooked up to an Apple Xserve RAID with a 2.3Tbyte ptn
that was created by the same system that is now giving trouble.

My problem is that mount (2.12-4.backports.org.1) fails to mount this
partition. It worked fine before, but stopped working after a power
outage. Before I was using mount version 2.11n-7woody1 (the stock debian
'woody' version). I upgraded to the backports.org version of mount after 
this problem appeared, but it didn't help.

The symptom is -
# mount /dev/sdb1
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
         or too many mounted file systems
         (aren't you trying to mount an extended partition,
         instead of some logical partition inside?)

My question to you is: where to look for help, if not here.
Do I need to upgrade mount? fdisk?
Am I missing a kernel module? I did a grep through the kernel-doc-2.6.7
tree for EFI and GPT and didn't find much information relevant to this


More information
The filesystem is ext3 but I don't have a note of the command used to 
create it. I do have the ext3 module loaded.

This filesystem is just data, it's not a booting issue.
In fact I've commented the fstab entry out so I can get a clean
boot, and am now trying to mount the fs on a fully running system.
I uncommented the entry after boot.

The fstab entry looks like this
# <file system> <mount point>   <type>  <options>  <dump>  <pass>
/dev/sdb1      /export/archive01   ext3    defaults  0 2

To get this large a partition, I was forced to partition with a
self-built parted (1.6.19, which supports using a gpt disk label).
This worked ok, and parted still seems happy with the partition:

# /local/sbin/parted /dev/sdb print
Disk geometry for /dev/sdb: 0.000-2289288.000 megabytes
Disk label type: gpt
Minor    Start       End     Filesystem  Name                  Flags
1          0.017 2289287.983  ext3
Information: Don't forget to update /etc/fstab, if necessary.

Fdisk is not entirely happy however. (util-linux, 2.12-4.backports.org)
# fdisk -l /dev/sdb
You must set cylinders.
You can do this from the extra functions menu.

Disk /dev/sdb: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

     Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      267350  2147483647+  ee  EFI GPT
Partition 1 has different physical/logical beginnings (non-Linux?):
       phys=(0, 0, 1) logical=(0, 0, 2)
Partition 1 has different physical/logical endings:
       phys=(1023, 254, 63) logical=(267349, 89, 4)

Nor is e2fsprogs (1.35-5.backports.org.1)
# e2fsck /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
      e2fsck -b 8193 <device>

Trying e2fsck -b 8193 /dev/sdb1 gives the same result.

# tune2fs -l /dev/sdb1
tune2fs 1.35 (28-Feb-2004)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.

I tried turning on EFI_PARTITION in the kernel and rebuilding.
This doesn't help, the kernel just wedges itself during the boot,
shortly after starting kjournald and mounting the ext3 partitions on 
the boot disk, /dev/sda (a 73GB scsi disk).

More information about the Ext3-users mailing list