Do you only use the parted "mkfs" or do you actually use the mke2fs
from e2fsprogs?
The script does this
parted -s /dev/sdb1 print
parted -s /dev/sdb1 mklabel gpt
parted -s /dev/sdb1 print
parted -s /dev/sdb1 mkpart primary 0 10
parted -s /dev/sdb1 print
parted -s /dev/sdb1 mke2fs 1 ext2
parted -s /dev/sdb1 print
Hmm, I don't use parted often, but does it make sense to be making a GPT
disklabel on /dev/sdb1 instead of making it on /dev/sdb?
ooops - misquote on my part. I was indeed using /dev/sdb for this.
I was translating from a shell script that uses a variable for the
disk device and the partition, and confused the two when translating.
Note also that there is actually no need to make a partition at all if
you are just going to use the whole device for the filesystem. This
is particularly interesting with some RAID hardware, since the partition
table adds a 512-byte offset to every single IO, and this can cause
some noticable performance problems.
Just do "mke2fs -j /dev/sdb" and be happy.
ok, I'll give that a whirl.
ah, of course. I thought findsuper would respect the partition boundaries
and stop at the "end" of the filesystem. It did that pre-reboot, e.g. my
10Mbyte test above
It DOES respect the partition boundaries, actually. In fact, if you
point it at a partition (instead of the parent device) it should not
be POSSIBLE for it to read beyond the end of the partition, and the
kernel should prevent it.
starting at 0, with 512 byte increments
thisoff block fs_blk_sz blksz grp last_mount
1024 1 10223 1024 0 Thu Jan 1 10:00:00 1970
8389632 8193 10223 1024 1 Thu Jan 1 10:00:00 1970
10468864: finished with errno 0
Post-reboot, I get this:
starting at 0, with 512 byte increments
thisoff block fs_blk_sz blksz grp last_mount
17920 17 10223 1024 0 Thu Jan 1 10:00:00 1970
8406528 8209 10223 1024 1 Thu Jan 1 10:00:00 1970
134235648 131089 511999995 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
This would seem to indicate your partition table is being corrupted.
right.
# /local/sbin/parted /dev/sdb print
Error: The primary GPT table is corrupt, but the backup appears ok, so
that will be used.
OK/Cancel? OK
Disk geometry for /dev/sdb: 0.000-2289288.000 megabytes
Disk label type: gpt
Minor Start End Filesystem Name Flags
1 0.017 10.000 ext2
Information: Don't forget to update /etc/fstab, if necessary.
I suspect this is part of the problem. The GPT disk label is being
written into /dev/sdb1 (which isn't really valid) and upon reboot the
"backup" is being found at the end of the device and doesn't match
the existing partition table on /dev/sdb.
Does your reasoning change given my silly mistake above,
ie I was running parted on /dev/sdb not /dev/sdb1.
# strace -o strace.e2fsck.post-parted /local/sbin/e2fsck -n /dev/sdb1
e2fsck 1.38 (30-Jun-2005)
Couldn't find ext2 superblock, trying backup blocks...
/local/sbin/e2fsck: Bad magic number in super-block while trying to open
/dev/sdb1
At this point, you are trying to access a filesystem with an offset from
the start of the partition. If you want to recover from this (your real
filesystem), what you should probably do is locate the expected start of
the filesystem using findsuper and then copy it onto your backup device:
dd if=/dev/orig of=/dev/backup bs=offset skip=1
The backup superblocks should have a byte offset of {1,3,5,...} * 32768 * 4096
from the start of the device, so subtracting this from the actual offsets
found will tell you where the filesystem is supposed to start. Checking the
first few (non group = 0) backup superblocks should make it pretty clear
where the filesystem is supposed to start.
I'll take a poke at this.
Assuming there is a problem with GPT labels, can you advise where to
report this? parted-bug, or bugzilla.kernel.org? Or both?
Cheers
Vince
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
