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
problem.
Thanks
Vince
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).
On Oct 31, 2005 19:33 +1100, Vincent McIntyre wrote:> 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?)It sounds like you have overflowed the end of the 2TB device limit and clobbered the beginning of your filesystem. This can happen if the SCSI driver, kernel, or even ext3 isn't handling offsets > 2^31 properly. I know RH has only recently started supporting ext3 filesystems > 2TB, and it isn't clear that all drivers handle this properly yet.> # 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.Please update your e2fsprogs to the latest. You also need to use "e2fsck -b 32768" (or multiple thereof) for such large filesystems. I think newer e2fsprogs will print this message properly in that case. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
thanks for your response, Andreas.> It sounds like you have overflowed the end of the 2TB device limit and > clobbered the beginning of your filesystem. This can happen if the > SCSI driver, kernel, or even ext3 isn't handling offsets > 2^31 properly. > I know RH has only recently started supporting ext3 filesystems > 2TB, > and it isn't clear that all drivers handle this properly yet.This box is using the fusion mpt drivers as in 2.6.7 - mptbase,mptscsih etc. Do you recall any >2Tb issue being fixed in later kernels? When the machine was last in a good state, the filesystem had 1.5Tbyte used, ie as far as I can tell nothing would have written past 2Tb, although I suppose there is no guarantee the space is used up in order of increasing offset. The filesystem was exported over NFS, and was being written to by client machines. It is using NFSv3 (nfs-kernel-server 1.0-2woody3). Worked great for several months.> Please update your e2fsprogs to the latest. You also need to use > "e2fsck -b 32768" (or multiple thereof) for such large filesystems. > I think newer e2fsprogs will print this message properly in that case. >I downloaded 1.38 from sourceforge and built it. No change in behaviour. I tried e2fsck with block offsets from 1025 to 4194305 in steps of 1024. I also tried dumpe2fs with the same range of offsets, also nothing. I've attached an strace of dumpe2fs, perhaps it is helpful? Another question. The e2fsck(8) manpage says the superblocks are at - Blocksize -b 1k 8193 2k 16384 4k 32768 Why is the superblock offset for 1k at 8193, not 8192? Is that an error in the manpage? Or should it be that the 2k, 4k block offsets should be odd, ie 16385, 32769? This article suggests the latter - http://www2.linuxjournal.com/article/0193 -------------- next part -------------- A non-text attachment was scrubbed... Name: log.dumpe2fs.gz Type: application/octet-stream Size: 1027 bytes Desc: URL: <http://listman.redhat.com/archives/ext3-users/attachments/20051101/2379eab4/attachment.obj>