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

Re: ext3 + fs > 2Tbyte



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


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