On Wed, 09 May 2007 10:21:44 -0500
Eric Sandeen <sandeen@xxxxxxxxxx> wrote:
> Valerie Clement wrote:
> > Jose R. Santos wrote:
> >> I think this has more to do with the fact that I'm on a 32bit
> >> architecture and there are still a couple places where blocks are
> >> represented using "unsigned long". I'm trying to get access to a 64bit
> >> arch to confirm this.
> >>
> >> -JRS
> >>
> > Oh, I didn't catch that you use a 32-bit system.
> > On 32-bit architectures, the page cache index size imposes a 16TB limit
> > on the filesystem size (with 4KB blocksize). So you need a 64-bit system
> > for your test.
> > Valérie
>
> hm, the mount never should have gotten far enough to fail due to this,
> should it have?
>
> Jose, what exactly failed? I see references to debugfs failing, but
> also kernel logs...
debugfs 1.39-tyt3 (29-Apr-2007)
/dev/mapper/testdb: Can't read an inode bitmap while reading inode bitmap
dumpe2fs 1.39-tyt3 (29-Apr-2007)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 1377370d-bc15-42c0-90bc-50e86bd86198
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype 64bit spar
...
Journal backup: inode blocks
misc/dumpe2fs: Attempt to read block from filesystem resulted in short read whil
e reading journal inode
> Jose, you mentioned that some blocks are still "unsigned long" on
> 32-bits... they shouldn't be, the LBD work should have fixed all those
> long ago. But there is still the 16TB page cache limit in force.
Found this in mke2fs.c
unsigned long blocks = EXT2_BLOCKS_COUNT(fs->super);
unsigned long start;
which are later uses to wipe out any MD RAID metadata at the end of the
device. and in parse_extended_opts()
unsigned long resize, bpg, rsv_groups;
...
if (resize <= EXT2_BLOCKS_COUNT(param)) {
Both of these cases should not affect what I was doing since I'm not
resizing or my device did not have any RAID metadata on the partition.
I believe I spotted similar cases yesterday in libext2fs but I don't
recall where. I will check.
-JRS
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
