linux-ext4 - Re: Creating a >32bit blocks filesystem.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070509113428.760f453a@gara>
Date:	Wed, 9 May 2007 11:34:28 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Valerie Clement <valerie.clement@...l.net>,
	linux-ext4@...r.kernel.org
Subject: Re: Creating a >32bit blocks filesystem.

On Wed, 09 May 2007 10:21:44 -0500
Eric Sandeen <sandeen@...hat.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html