ext3 + fs > 2Tbyte

Vincent.McIntyre at csiro.au Vincent.McIntyre at csiro.au
Tue Nov 1 13:37:06 UTC 2005

>>> Please update your e2fsprogs to the latest.  You also need to use
>>> "e2fsck -b 32768" (or multiple thereof) for such large filesystems.
>>> I think newer e2fsprogs will print this message properly in that case.
> You might also need to add "-B 4096".

I gave that a try as well (and -B 8192), with the same results.

I tried to make a copy of the first part of the filesystem with dd;

   # dd if=/dev/sdb1 of=/tmp/sdb1.dd bs=1 count=16384 \

This returned a file supposedly 16384 bytes long , but it didn't make
much sense - looking at it with 'od' or 'hexdump' I get only 17 lines
of output, not the roughly 178 I get for the same exercise with a good
ext3 filesystem. (The /tmp filesystem has 128-byte inodes.)

The output appears to be just the EFI GPT partition label.

I'm starting to suspect something in the raid device is in a strange
state. Or that the whole filesystem has just totally disappeared. :(

A bit more digging in the logs found this, from the first boot when
power was reapplied
  sdb : very big device. try to use READ CAPACITY(16).
  kernel: SCSI device sdb: 4688461824 512-byte hdwr sectors (2400492 MB)
  kernel: SCSI device sdb: drive cache: write back
  kernel:  /dev/scsi/host2/bus0/target0/lun0: p1
  kernel: Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0
so far so good - and then (eek)
  kernel: VFS: Can't find ext3 filesystem on dev sdb1.
when kjournald attempts to take a peek at the journal.

>> I downloaded 1.38 from sourceforge and built it. No change in behaviour.
>> I tried e2fsck with block offsets from 1025 to 4194305 in steps of 1024.
>> I also tried dumpe2fs with the same range of offsets, also nothing.
>> Another question. The e2fsck(8) manpage says the superblocks are at -
>>  Blocksize     -b
>>  1k          8193
>>  2k         16384
>>  4k         32768
>> Why is the superblock offset for 1k at 8193, not 8192?
> Because the ext[23] superblock is at 1024 bytes offset from the
> beginning of the device.  For 1kB blocksize this is a whole block
> so the filesystem starts at block 1, while for larger blocksize
> this is still in block 0.  Backup superblocks are at block offsets:
> (blocksize * 8) * {3,5,7}^n, n={0,1,2,3...}

I'm starting to get this, thanks for your patience.
I tried all the feasible values of -b less than 2147483647,
as I mention above. I did not try larger block sizes than 8192.

I since found these links which fill out the picture a bit more.

Any further thoughts appreciated.


More information about the Ext3-users mailing list