ext3 + fs > 2Tbyte

[Vincent McIntyre]

Hi again

I unplugged the original xraid and did some tests on a non-production one,
building larger and larger filesystems, mounting, & dismounting.
I can reproduce the problem with this sequence:

* boot with xraid device plugged in, kernel 2.6.7-1-686-smp
     (packaged as 2.6.7-1.backports.org.1)
* install a gpt disklabel with parted (-1.6.24 rather than 1.6.19)
* make an ext2 filesystem as big as the disk with parted
* mount - it mounts ok
* umount
* tune2fs -j (-1.38)
* mount - it mounts ok (-2.12)
* umount (-2.12)
* reboot
* try to mount - it fails.
     (the filesystem is not mentioned in /etc/fstab, the system should
      not be attempting to mount it of fsck it at boot time)

No files were written to the filesystem during the test sequence.

I have not yet tried filesystems smaller than 2Tb across reboots.
I expect it will work, but I will try that shortly to check.


findsuper tells me there are superblocks, but fs_blk_sz changes (!?)
# /root/e2fsprogs-1.38/misc/findsuper /dev/sdb1
starting at 0, with 512 byte increments
        thisoff     block fs_blk_sz  blksz grp last_mount
          17920        17 586057719  4096    0 Thu Jan  1 10:00:00 1970
      134234624    131088 586057719  4096    1 Thu Jan  1 10:00:00 1970
      134235648    131089 586057719  4096    1 Thu Jan  1 10:00:00 1970
      209733120    204817   1023983  1024   25 Thu Jan  1 10:00:00 1970
      226510336    221201   1023983  1024   27 Thu Jan  1 10:00:00 1970
      402670080    393232 586057719  4096    3 Thu Jan  1 10:00:00 1970
      402671104    393233 586057719  4096    3 Thu Jan  1 10:00:00 1970
      411059712    401425   1023983  1024   49 Thu Jan  1 10:00:00 1970
      671105536    655376 586057719  4096    5 Thu Jan  1 10:00:00 1970
      671106560    655377 586057719  4096    5 Thu Jan  1 10:00:00 1970
      679495168    663569   1023983  1024   81 Thu Jan  1 10:00:00 1970
      939540992    917520 586057719  4096    7 Thu Jan  1 10:00:00 1970
      939542016    917521 586057719  4096    7 Thu Jan  1 10:00:00 1970
     1207976448   1179664 586057719  4096    9 Thu Jan  1 10:00:00 1970
     1207977472   1179665 586057719  4096    9 Thu Jan  1 10:00:00 1970
     3355460096   3276816 586057719  4096   25 Thu Jan  1 10:00:00 1970
     3355461120   3276817 586057719  4096   25 Thu Jan  1 10:00:00 1970
     3623895552   3538960 586057719  4096   27 Thu Jan  1 10:00:00 1970
     3623896576   3538961 586057719  4096   27 Thu Jan  1 10:00:00 1970
     6576685568   6422544 586057719  4096   49 Thu Jan  1 10:00:00 1970
     6576686592   6422545 586057719  4096   49 Thu Jan  1 10:00:00 1970
    10871652864  10616848 586057719  4096   81 Thu Jan  1 10:00:00 1970
    10871653888  10616849 586057719  4096   81 Thu Jan  1 10:00:00 1970
    16777232896  16384016 586057719  4096  125 Thu Jan  1 10:00:00 1970
    16777233920  16384017 586057719  4096  125 Thu Jan  1 10:00:00 1970
^C
This is not looking good...

Your nice od trick tells me slightly different locations for the
superblock signatures -
# od -Ax -tx4 /dev/sdb1 | \
   grep "^[0-9a-f]*30 [0-9a-f]* [0-9a-f]* 000[1-3]ef53 "
004630 436a93dd 001e0000 0001ef53 00000001
8004630 00000000 001e0000 0001ef53 00000001
c804630 00000000 001e0000 0001ef53 00000001
d804630 00000000 001e0000 0001ef53 00000001
18004630 00000000 001e0000 0001ef53 00000001
18804630 00000000 001e0000 0001ef53 00000001
28004630 00000000 001e0000 0001ef53 00000001
28804630 00000000 001e0000 0001ef53 00000001
38004630 00000000 001e0000 0001ef53 00000001
48004630 00000000 001e0000 0001ef53 00000001
c8004630 00000000 001e0000 0001ef53 00000001
d8004630 00000000 001e0000 0001ef53 00000001
88004630 00000000 001e0000 0001ef53 00000001
^C

0x004630 corresponds to byte offset 17968, 48 bytes away.
Is this explainable by the position of the superblock signature within
the disk block?
0x8004630 corresponds to 134220222, delta=14400. This is confusing me.

So I tried a few e2fsck runs. I know I'm probably being dense but none
of these worked:
e2fsck -n -b 16        -B 4096 /dev/sdb1
e2fsck -n -b 17        -B 4096 /dev/sdb1
e2fsck -n -b 18        -B 4096 /dev/sdb1
e2fsck -n -b 204816    -B 1024 /dev/sdb1
e2fsck -n -b 204817    -B 1024 /dev/sdb1
e2fsck -n -b 204818    -B 1024 /dev/sdb1
e2fsck -n -b 221200    -B 1024 /dev/sdb1
e2fsck -n -b 221201    -B 1024 /dev/sdb1
e2fsck -n -b 221202    -B 1024 /dev/sdb1
e2fsck -n -b 1179664   -B 4096 /dev/sdb1
e2fsck -n -b 1179665   -B 4096 /dev/sdb1
e2fsck -n -b 6422544   -B 4096 /dev/sdb1
e2fsck -n -b 6422545   -B 4096 /dev/sdb1
e2fsck -n -b 10616848  -B 4096 /dev/sdb1
e2fsck -n -b 10616849  -B 4096 /dev/sdb1

(The e2fsck manpage could be a tiny bit clearer in that - I think -
  it means you to use -b <blocknumber>, not -b <offset_to_superblock>)

oh, and just trying to mount does not work, as one might expect.
# mount -text2 /dev/sdb1 /tmp/a
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?)

I did straces of the e2fsck before and after the reboot; would it help
to send those?

Thanks again
Vince