linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jose R. Santos" <jrs@us.ibm.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Valerie Clement <valerie.clement@bull.net>, linux-ext4@vger.kernel.org
Subject: Re: Creating a >32bit blocks filesystem.
Date: Wed, 9 May 2007 11:34:28 -0500	[thread overview]
Message-ID: <20070509113428.760f453a@gara> (raw)
In-Reply-To: <4641E708.1090109@redhat.com>

On Wed, 09 May 2007 10:21:44 -0500
Eric Sandeen <sandeen@redhat.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

  reply	other threads:[~2007-05-09 16:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03 19:08 Creating a >32bit blocks filesystem Jose R. Santos
2007-05-04 14:58 ` Valerie Clement
2007-05-07 16:19   ` Jose R. Santos
2007-05-07 18:36     ` Jose R. Santos
2007-05-09 12:16     ` Valerie Clement
2007-05-09 13:55       ` Jose R. Santos
2007-05-09 14:57         ` Valerie Clement
2007-05-09 15:21           ` Eric Sandeen
2007-05-09 16:34             ` Jose R. Santos [this message]
2007-05-09 17:02               ` Eric Sandeen
2007-05-09 15:29           ` Jose R. Santos
2007-05-09 16:15           ` Andreas Dilger
2007-05-09 17:18   ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070509113428.760f453a@gara \
    --to=jrs@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=valerie.clement@bull.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).