The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Goldwyn Rodrigues <goldwyn_r@myrealbox.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Breaking ext2 file size limit of 2TB
Date: Mon, 28 Jun 2004 11:53:05 -0600	[thread overview]
Message-ID: <20040628175305.GG15166@schnapps.adilger.int> (raw)
In-Reply-To: <1088230193.9825981cgoldwyn_r@myrealbox.com>

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

On Jun 26, 2004  11:39 +0530, Goldwyn Rodrigues wrote:
> I am using i386 architecture.
> 
> > If we started using larger blocksizes for systems that have larger than
> > 4kB pages (i.e. not i386) this would become an issue.  At some point
> > having giant files w/o extents is pointless (performance is too bad),
> > so we could also put the high blocks count in as part of the extent data
> > (e.g. i_blocks[14]) since the format would be gratuitously incompatible
> > anyways.
> 
> I din't quite understand this point. Do you mean to say that we keep such
> data elsewhere if required, and then read such data only for large systems.
> As in, do another block read?

No, my point was that on i386 systems there is also a limit at 4TB so
your patch will only serve to double the maximum file size on such
systems.  On non-i386 systems this patch makes somewhat more sense,
but even so it is very inefficient to have enormous files allocating
a billion blocks or even more at larger block sizes.

On i386 we are limited to 4kB pages and this means after we fill the
triple indirect block we can't grow any larger (4096 / 4) ^ 3 * 4096 =
4TB.  However, on ia64 and other 64-bit platforms that have larger page
sizes we can use larger blocks for the filesystem (up to 64kB) and this
increases the triple indirect limit a lot (65536 / 4) ^ 3 * 65536 = 256PB
= 58 bits, at the sake of no longer being mountable on i386 machines.

I think that to have "useful" growth in file sizes we need to take a
hard look at the extents code already written by Alex.  Even with that
we need to be able to store a blocks count > 2^32 so this work isn't
incompatible with that, but if it takes 30 minutes to unlink a giant
file with a billion blocks I don't think just removing the i_blocks
limit will have helped us very much by itself.

Yes, the extent code is incompatible with the current layout (as is this
change), but if we add at least read support (write support separately
selectable if there is some objection to the incompatible change) for
extents to 2.6 then it can become a full-fledged member of ext3 in the
2.8 kernel.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-06-28 17:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-26  6:09 [PATCH] Breaking ext2 file size limit of 2TB Goldwyn Rodrigues
2004-06-28 17:53 ` Andreas Dilger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-06-28  7:12 Goldwyn Rodrigues
2004-06-28  9:30 ` Jan-Benedict Glaw
2004-06-26  6:11 Goldwyn Rodrigues
2004-06-26 14:13 ` Jan-Benedict Glaw
2004-06-25 13:04 Goldwyn Rodrigues
2004-06-25 13:34 ` Jan-Benedict Glaw
2004-06-25 19:12 ` Andreas Dilger

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=20040628175305.GG15166@schnapps.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=goldwyn_r@myrealbox.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox