From: Daniel Phillips <phillips@bonn-fries.net>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
phillips@bonn-fries.net (Daniel Phillips)
Cc: reiser@namesys.com (Hans Reiser),
alan@lxorguk.ukuu.org.uk (Alan Cox),
volodya@mindspring.com,
ajschrotenboer@lycosmail.com (Adam Schrotenboer),
linux-kernel@vger.kernel.org (lkml)
Subject: Re: Stability of ReiserFS onj Kernel 2.4.x (sp. 2.4.[56]{-ac*}
Date: Mon, 16 Jul 2001 14:49:36 +0200 [thread overview]
Message-ID: <01071614493604.06482@starship> (raw)
In-Reply-To: <200107160022.f6G0MBn310960@saturn.cs.uml.edu>
In-Reply-To: <200107160022.f6G0MBn310960@saturn.cs.uml.edu>
On Monday 16 July 2001 02:22, Albert D. Cahalan wrote:
> Daniel Phillips writes:
> > Or we could introduce the notion of logical blocksize for each
> > block minor so that we can measure blocks in the same units the
> > filesystem uses. This would give us 16 TB while being able to stay
> > with 32 bits everywhere outside the block drivers themselves.
> >
> > We are not that far away from being able to handle 8K blocks, so
> > that would bump it up to 32 TB.
>
> This is like what the hard drive and BIOS industry has been doing.
> First we had the 528 MB limit. Then the 2 GB limit. Then the 4 GB
> limit. Then the 8.3 GB limit. Then the 33 GB limit. Then the 127 GB
> limit. All along the way, users are cursing the damn limits.
>
> An extra 4 bits buys us 6 years maybe. Nice, except that we
> already have people complaining. Maybe somebody remembers when
> the complaining started.
Well, that coincides nicely with the period when most of us will still
be using 32 bit processors, don't you think? If we solve the problem
of internal fragmentation (as Reiserfs has) and memory management then
we can keep going on up to 64K blocksize, giving a 256 TB limit. Not
too shabby. (Some things need fixing after that, e.g. Ext2 directory
entry record sizes.)
At the same time, the larger block size means that, to transfer a given
number of blocks at random locations, less time is spent seeking and
less time in setup. Larger blocks are good - there's a reason why the
industry is heading in that direction. If it also helps us with our
partition size limits, then why not take advantage of it. I'd say, do
both, use the logical blocksize measurements and provide 64 bit block
numbers as an option.
Note that there is a bug-by-design that comes from measuring device
capacity in 1K blocks the way we do now: on a device with 512 byte
blocks we can't correctly determine when a block access is out of
range. Measuring in logical block size would fix that cleanly.
--
Daniel
next prev parent reply other threads:[~2001-07-16 12:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-14 23:54 Stability of ReiserFS onj Kernel 2.4.x (sp. 2.4.[56]{-ac*} Adam Schrotenboer
2001-07-15 0:01 ` Thomas Zimmerman
2001-07-15 16:00 ` volodya
2001-07-15 16:08 ` Alexander Viro
2001-07-16 0:50 ` volodya
2001-07-16 0:54 ` Ragnar Kjørstad
2001-07-16 0:57 ` Alexander Viro
2001-07-16 1:22 ` volodya
2001-07-16 1:48 ` Ignacio Vazquez-Abrams
2001-07-15 16:33 ` Alan Cox
2001-07-15 16:44 ` Hans Reiser
2001-07-15 16:46 ` Alan Cox
2001-07-15 17:54 ` Hans Reiser
2001-07-15 18:17 ` Alan Cox
2001-07-16 13:27 ` Marco Colombo
2001-07-15 17:58 ` Rob Turk
2001-07-15 21:30 ` Daniel Phillips
2001-07-15 22:05 ` Hans Reiser
2001-07-15 22:18 ` Daniel Phillips
2001-07-16 0:22 ` Albert D. Cahalan
2001-07-16 12:49 ` Daniel Phillips [this message]
2001-07-17 19:40 ` Rob Landley
2001-07-16 17:19 ` Jussi Laako
2001-07-16 17:53 ` Daniel Phillips
2001-07-16 19:16 ` Hans Reiser
2001-07-16 21:00 ` Jussi Laako
2001-07-16 22:28 ` Daniel Phillips
2001-07-18 0:58 ` Dan Hollis
2001-07-16 4:39 ` Mike A. Harris
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=01071614493604.06482@starship \
--to=phillips@bonn-fries.net \
--cc=acahalan@cs.uml.edu \
--cc=ajschrotenboer@lycosmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
--cc=volodya@mindspring.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox