All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Jussi Laako <jlaako@pp.htv.fi>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: Stability of ReiserFS onj Kernel 2.4.x (sp. 2.4.[56]{-ac*}
Date: Mon, 16 Jul 2001 19:53:59 +0200	[thread overview]
Message-ID: <0107161953590C.06482@starship> (raw)
In-Reply-To: <E15LopT-0004Cm-00@the-village.bc.nu> <01071523304400.06482@starship> <3B53221B.28B8D5A1@pp.htv.fi>
In-Reply-To: <3B53221B.28B8D5A1@pp.htv.fi>

On Monday 16 July 2001 19:19, Jussi Laako wrote:
> Daniel Phillips wrote:
> > We are not that far away from being able to handle 8K blocks, so
> > that would bump it up to 32 TB.
>
> That's way too small. Something like 32 PB would be better... ;)

Are you serious?  What kind of application are you running?

> We need at least one extra bit in volume/file size every year.

OK, well hmm, then in 1969 we needed a volume size of 4K.  Um, it's 
probably more accurate to use 18 months as the doubling period.

Anyway, that's what the 64 bit option for buffer_head->b_blocknr is 
supposed to handle.  The question is, is it necessary to go to a 
uniform 64 bit quantity for all users regardless of whether they feel 
restricted by a 32 TB volume size limit or not.

/me figures it will be 9 years before he even has a 1 TB disk in his 
laptop

OK, I looked again and saw the smiley.  Sometimes it's hard to tell 
what's outrageous when talking about disk sizes.

--
Daniel

  reply	other threads:[~2001-07-16 17:50 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
2001-07-17 19:40           ` Rob Landley
2001-07-16 17:19         ` Jussi Laako
2001-07-16 17:53           ` Daniel Phillips [this message]
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=0107161953590C.06482@starship \
    --to=phillips@bonn-fries.net \
    --cc=jlaako@pp.htv.fi \
    --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 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.