All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.