All of lore.kernel.org
 help / color / mirror / Atom feed
From: Padraig Brady <padraig@antefacto.com>
To: Peter Chubb <peter@chubb.wattle.id.au>
Cc: Jeremy Andrews <jeremy@kerneltrap.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove 2TB block device limit
Date: Sat, 11 May 2002 19:13:39 +0100	[thread overview]
Message-ID: <3CDD5F53.3080202@antefacto.com> (raw)
In-Reply-To: <15579.16423.930012.986750@wombat.chubb.wattle.id.au>	<20020510084713.43ce396e.jeremy@kerneltrap.org> <15580.7052.396951.568702@wombat.chubb.wattle.id.au>

I found the following related graph from Mr. Cahalan very informative:
http://www.cs.uml.edu/~acahalan/linux/ext2.gif
I just might get around to updating/expanding it.

Padraig.

Peter Chubb wrote:
>>>>>>"Jeremy" == Jeremy Andrews <jeremy@kerneltrap.org> writes:
>>>>>
> 
> Jeremy> Peter, Out of curiousity, what then does the new filesystem
> Jeremy> limit become, on a 64-bit system?  Will all filesystems
> Jeremy> support your changes?
> 
> This depends on the file system.
> See
> 	 http://www.gelato.unsw.edu.au/~peterc/lfs.html
> (which I'm intending to update next week, after some testing to
> check the new limits with my new code -- I found the 1TB limit in
> the generic code (someone using a signed int instead of unsigned long))
> 
> There are three different limits that apply:
> 
>  --- The physical layout on disc (e.g., ext2 uses 32-bit for block
>      numbers within a file system; thus the max size is
>      (2^32-1)*block_size;  although it's theoretically possible to use
>      larger blocksizes, the current toolchain has a maximum of 4k,
>      thus the largest size of an ext[23] filesystem is ((2^32)-1)*4k
>      bytes --- around 16TB)
> 
>      It's extremely unlikely that you'd want to use a non-journalled
>      file system on such a large partition, so your best bets are
>      reiserfs, jfs or XFS.  jfs and xfs work well on enormous
>      partitions on other platforms; the current version of reiserfs is
>      somewhat limited, but version 4 will allow larger file systems.
> 
> 
>  --- Limitations imposed by the partitioning scheme.
>      As far as I know, only the EFI GUID partitioning scheme uses
>      64-bit block offsets, so under any other scheme you're limited to
>      2^32 or 2^31 blocks per disc; some use the underlying hardware
>      sector size, some use a block size that's  multiple of this.
> 
>  --- The page cache limit (which on a 32-bit system is 16TB; on a 64
>      bit system is 18 EB
> 
> 
> Jeremy>   Mind if I quote what you say on my webpage?
> 
> Go ahead
> 
> --
> Peter Chubb
> peterc@gelato.unsw.edu.au	http://www.gelato.unsw.edu.au
> -



  parent reply	other threads:[~2002-05-11 18:15 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-10  3:36 [PATCH] remove 2TB block device limit 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 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-10  3:53 Neil Brown
     [not found] <1060250300@toto.iv>
2002-05-13 10:28 ` 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
2002-05-14  2:58         ` Peter Chubb
2002-05-14  7:22           ` Christoph Hellwig
2002-05-14  7:21         ` Christoph Hellwig
2002-05-15  9:41 Hirotaka Sasaki
2002-05-15 21:49 ` Steve Lord
     [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

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=3CDD5F53.3080202@antefacto.com \
    --to=padraig@antefacto.com \
    --cc=jeremy@kerneltrap.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter@chubb.wattle.id.au \
    /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.