From: Matthew Wilcox <matthew@wil.cx>
To: LA Walsh <law@sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: 64-bit block sizes on 32-bit systems
Date: Mon, 26 Mar 2001 18:18:03 +0100 [thread overview]
Message-ID: <20010326181803.F31126@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <3ABF70B9.573C2F85@sgi.com>
In-Reply-To: <3ABF70B9.573C2F85@sgi.com>; from law@sgi.com on Mon, Mar 26, 2001 at 08:39:21AM -0800
On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> I vaguely remember a discussion about this a few months back.
> If I remember, the reasoning was it would unnecessarily slow
> down smaller systems that would never have block devices in
> the 4-28T range attached.
4k page size * 2GB = 8TB.
i consider it much more likely on such systems that the page size will
be increased to maybe 16 or 64k which would give us 32TB or 128TB.
you keep on trying to increase the size of types without looking at
what gcc outputs in the way of code that manipulates 64-bit types.
seriously, why don't you just try it? see what the performance is.
see what the code size is. then come back with some numbers. and i mean
numbers, not `it doesn't feel any slower'.
personally, i'm going to see what the situation looks like in 5 years time
and try to solve the problem then. there're enough real problems with the
VFS today that i don't feel inclined to fix tomorrow's potential problems.
--
Revolutions do not require corporate support.
next prev parent reply other threads:[~2001-03-26 17:19 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-26 16:39 LA Walsh
2001-03-26 17:18 ` Matthew Wilcox [this message]
2001-03-26 17:47 ` Andreas Dilger
2001-03-26 18:09 ` Matthew Wilcox
2001-03-26 18:37 ` Eric W. Biederman
2001-03-26 19:36 ` Martin Dalecki
2001-03-26 23:03 ` AJ Lewis
2001-03-26 19:05 ` Scott Laird
2001-03-26 19:09 ` Andreas Dilger
2001-03-26 20:31 ` Dan Hollis
2001-03-26 19:20 ` Rik van Riel
2001-03-26 20:14 ` Jes Sorensen
2001-03-26 17:58 ` Eric W. Biederman
2001-03-28 8:06 ` Matthew Wilcox
2001-03-26 17:35 LA Walsh
2001-03-26 18:01 Manfred Spraul
2001-03-26 18:07 ` Matthew Wilcox
2001-03-26 19:40 ` LA Walsh
2001-03-26 21:53 ` Manfred Spraul
2001-03-26 22:07 ` LA Walsh
2001-03-26 19:26 Jesse Pollard
2001-03-26 21:27 Jesse Pollard
2001-03-26 22:07 ` Jonathan Morton
2001-03-27 4:14 ` Jesse Pollard
2001-03-27 17:22 LA Walsh
[not found] <Pine.LNX.4.30.0103270022500.21075-100000@age.cs.columbia.edu>
[not found] ` <3AC0CA9C.3D804361@sgi.com>
2001-03-27 19:00 ` Jan Harkes
2001-03-27 19:30 Jesse Pollard
2001-03-27 19:57 Jesse Pollard
2001-03-27 20:20 ` Jan Harkes
2001-03-27 21:55 ` LA Walsh
2001-03-27 22:23 Jesse Pollard
2001-03-27 23:56 ` Steve Lord
2001-03-28 8:09 ` Brad Boyer
2001-03-28 14:53 ` Dave Kleikamp
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=20010326181803.F31126@parcelfarce.linux.theplanet.co.uk \
--to=matthew@wil.cx \
--cc=law@sgi.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®