From: Eric Sandeen <sandeen@redhat.com>
To: Valerie Clement <valerie.clement@bull.net>
Cc: "Jose R. Santos" <jrs@us.ibm.com>, linux-ext4@vger.kernel.org
Subject: Re: Creating a >32bit blocks filesystem.
Date: Wed, 09 May 2007 10:21:44 -0500 [thread overview]
Message-ID: <4641E708.1090109@redhat.com> (raw)
In-Reply-To: <4641E13D.906@bull.net>
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...
Things like debugfs will have issues with very large block devices due
to maximum file size restrictions on 32-bit platforms, due to the page
cache issue Valerie mentions... But trying to open it should give EFBIG
I'd think?
And mounting such a filesystem on a 32-bit system should also get
rejected early (and cleanly).
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.
-Eric
next prev parent reply other threads:[~2007-05-09 15:25 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 [this message]
2007-05-09 16:34 ` Jose R. Santos
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=4641E708.1090109@redhat.com \
--to=sandeen@redhat.com \
--cc=jrs@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--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.