All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.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: Fri, 10 May 2002 17:46:23 -0600	[thread overview]
Message-ID: <20020510234623.GC12975@turbolinux.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>

On May 11, 2002  05:12 +1000, Peter Chubb wrote:
> 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))

Any chance you could rename this from "LFS" to something else (e.g. LBD
for Large Block Device).  LFS == Large File Summit which describes the
use/access of > 2GB _files_ on 32-bit systems under Unix.

> 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)

For 64-bit systems like Alpha, it is relatively easy to use 8kB blocks for
ext3.  It has been discouraged because such a filesystem is non-portable
to other (smaller page-sized) filesystems.  Maybe this rationale should
be re-examined - I could probably whip up a configure option for
e2fsprogs to allow 8kB blocks in a few hours.

Does x86-64 and/or ia64 actually _use_ > 4kB page sizes?  If so, it
may be more worthwhile to allow larger block sizes with e2fsprogs.
It may be that the kernel supports >4kB blocks already on systems with
larger PAGE_SIZE, I don't know (no way for me to test this).

>      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.

I find it somewhat ironic that you suggest reiserfs over ext3, when in
fact they both currently have the same 16TB filesystem limit.  On your
web page, you say the ext[23] limit is 1TB, which it definitely is not
(unless there are bugs in the code).  There is currently a 16TB filesystem
limit for 4kB blocks, but there are plans towards fixing that also.

>  --- 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.

LVM does not need to have partitions, and presumably EVMS using Linux
or AIX LVM devices doesn't either.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


  reply	other threads:[~2002-05-10 23:48 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 [this message]
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
  -- 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=20020510234623.GC12975@turbolinux.com \
    --to=adilger@clusterfs.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.