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
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
