[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3 + fs > 2Tbyte



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]