From: Andrew Morton <akpm@zip.com.au>
To: Peter Chubb <peter@chubb.wattle.id.au>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, torvalds@transmeta.com,
axboe@suse.de, martin@dalecki.de, neilb@cse.unsw.edu.au
Subject: Re: [PATCH] remove 2TB block device limit
Date: Mon, 13 May 2002 19:09:59 -0700 [thread overview]
Message-ID: <3CE071F7.347C78B5@zip.com.au> (raw)
In-Reply-To: <20020513131339.A4610@infradead.org> <15584.23204.925373.44968@wombat.chubb.wattle.id.au>
Peter Chubb wrote:
>
> ...
> Christoph> - why is the get_block block argument
> Christoph> a sector_t? It presents a logical filesystem block which
> Christoph> usually is larger than the sector, not to mention that for
> Christoph> the usual blocksize == PAGE_SIZE case a ulong is enough as
> Christoph> that is the same size the pagecache limit triggers.
>
> For filesystems that *can* handle logical filesystem blocks beyond the
> 2^32 limit (i.e., that use >32bit offsets in their on-disc format),
> the get_block() argument has to be > 32bits long. At the moment
> that's only JFS and XFS, but reiserfs version 4 looks as if it might
> go that way. We'll need this especially when the pagecache limit is
> gone.
I think Christoph's point is that a pagecache index is not a sector
number. We agree that we need to plan for taking it to 64 bits, but
it should be something different. Like pageindex_t, or whatever.
This:
--- linux-2.5.15/include/linux/mm.h Tue Apr 30 17:56:30 2002
+++ 25/include/linux/mm.h Mon May 13 19:08:21 2002
@@ -148,7 +148,7 @@ struct vm_operations_struct {
typedef struct page {
struct list_head list; /* ->mapping has some page lists. */
struct address_space *mapping; /* The inode (or ...) we belong to. */
- unsigned long index; /* Our offset within mapping. */
+ sector_t index; /* Our offset within mapping. */
atomic_t count; /* Usage count, see below. */
unsigned long flags; /* atomic flags, some possibly
updated asynchronously */
looks rather silly, no?
-
next prev parent reply other threads:[~2002-05-14 2:06 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1060250300@toto.iv>
2002-05-13 10:28 ` [PATCH] remove 2TB block device limit Peter Chubb
2002-05-13 12:13 ` Christoph Hellwig
2002-05-14 0:30 ` Peter Chubb
2002-05-14 1:36 ` Anton Altaparmakov
2002-05-16 20:32 ` Daniel Phillips
2002-05-14 2:09 ` Andrew Morton [this message]
2002-05-14 2:58 ` Peter Chubb
2002-05-14 7:22 ` Christoph Hellwig
2002-05-14 7:21 ` Christoph Hellwig
[not found] <581856778@toto.iv>
2002-05-17 0:04 ` Peter Chubb
2002-05-17 0:18 ` Daniel Phillips
2002-05-17 13:32 ` Jesse Pollard
2002-05-17 18:02 ` Daniel Phillips
2002-05-17 18:26 ` Jesse Pollard
2002-05-17 18:36 ` Andreas Dilger
2002-05-17 19:52 ` Daniel Phillips
2002-05-17 20:25 ` Andrew Morton
2002-05-17 15:26 ` Jason L Tibbitts III
2002-05-15 9:41 Hirotaka Sasaki
2002-05-15 21:49 ` Steve Lord
-- strict thread matches above, loose matches on Subject: below --
2002-05-10 3:53 Neil Brown
2002-05-10 3:36 Peter Chubb
2002-05-10 4:05 ` Andrew Morton
2002-05-10 8:43 ` Anton Altaparmakov
2002-05-10 9:04 ` Andrew Morton
2002-05-16 19:08 ` Daniel Phillips
2002-05-10 9:05 ` Jens Axboe
2002-05-10 9:53 ` Peter Chubb
2002-05-10 10:01 ` Jens Axboe
2002-05-10 11:43 ` Anton Altaparmakov
2002-05-10 4:51 ` Martin Dalecki
[not found] ` <20020510084713.43ce396e.jeremy@kerneltrap.org>
2002-05-10 19:12 ` Peter Chubb
2002-05-10 23:46 ` Andreas Dilger
2002-05-11 0:07 ` David Mosberger
2002-05-15 22:17 ` Andreas Dilger
2002-05-16 20:22 ` Daniel Phillips
2002-05-16 22:54 ` Andreas Dilger
2002-05-17 1:17 ` Daniel Phillips
2002-05-11 4:40 ` Peter Chubb
2002-05-15 13:49 ` Pavel Machek
2002-05-11 18:13 ` Padraig Brady
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=3CE071F7.347C78B5@zip.com.au \
--to=akpm@zip.com.au \
--cc=axboe@suse.de \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
--cc=neilb@cse.unsw.edu.au \
--cc=peter@chubb.wattle.id.au \
--cc=torvalds@transmeta.com \
/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.