From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200107160022.f6G0MBn310960@saturn.cs.uml.edu>
Subject: Re: Stability of ReiserFS onj Kernel 2.4.x (sp. 2.4.[56]{-ac*}
To: phillips@bonn-fries.net (Daniel Phillips)
Date: Sun, 15 Jul 2001 20:22:11 -0400 (EDT)
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)
In-Reply-To: <01071523304400.06482@starship> from "Daniel Phillips" at Jul 15, 2001 11:30:44 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/