ext3 + fs > 2Tbyte
Vincent.McIntyre at csiro.au
Vincent.McIntyre at csiro.au
Fri Nov 4 11:30:26 UTC 2005
>>> 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
More information about the Ext3-users
mailing list