From: Eric Sandeen <sandeen@redhat.com>
To: Robin Dong <hao.bigrat@gmail.com>
Cc: "Ted Ts'o" <tytso@mit.edu>, Andreas Dilger <adilger@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] Add new extent structure in ext4
Date: Mon, 30 Jan 2012 14:41:53 -0600 [thread overview]
Message-ID: <4F270091.3050000@redhat.com> (raw)
In-Reply-To: <CAFZ0FUXT-X146SEAHCcNh-bGARUTgLOSP1dCrqeOrT48REN+ow@mail.gmail.com>
On 1/23/12 6:51 AM, Robin Dong wrote:
> Hi Ted, Andreas and the list,
>
> After the bigalloc-feature is completed in ext4, we could have much more
> big size of block-group (also bigger continuous space), but the extent
> structure of files now limit the extent size below 128MB, which is not
> optimal.
>
> We could solve the problem by creating a new extent format to support
> larger extent size, which looks like this:
>
> struct ext4_extent2 {
> __le64 ee_block; /* first logical block extent covers */
> __le64 ee_start; /* starting physical block */
> __le32 ee_len; /* number of blocks covered by extent */
> __le32 ee_flags; /* flags and future extension */
> };
>
> struct ext4_extent2_idx {
> __le64 ei_block; /* index covers logical blocks from 'block' */
> __le64 ei_leaf; /* pointer to the physical block of the next level */
> __le32 ei_flags; /* flags and future extension */
> __le32 ei_unused; /* padding */
> };
>
> I think we could keep the structure of ext4_extent_header and add new
> imcompat flag EXT4_FEATURE_INCOMPAT_EXTENTS2.
>
> The new extent format could support 16TB continuous space and larger volumes.
(larger volumes?)
> What's your opinion?
>
I think that mailing list drama aside ;) Dave has a decent point that we shouldn't
allow structures to scale out further than the code *using* them can scale.
In other words, if we already have some trouble being efficient with 2^32 blocks
in a file, it is risky and perhaps unwise to allow even larger files, until
those problems are resolved. At a minimum, I'd suggest that such a change
should not go in until it is demonstrated that ext4 can, in general, handle such
large file sizes efficiently.
It'd be nice to be able to self-host large sparse images for large fs testing,
though.
I suppose bigalloc solves that a little, though with some backing store space
usage penalty. I suppose if a bigalloc fs is hosted on a bigalloc fs, things
should (?) line up and be reasonable.
-Eric
next prev parent reply other threads:[~2012-01-30 20:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 12:51 [RFC] Add new extent structure in ext4 Robin Dong
2012-01-23 18:59 ` Ted Ts'o
2012-01-23 23:17 ` Andreas Dilger
2012-01-24 13:34 ` Jan Kara
2012-01-24 17:32 ` Andreas Dilger
2012-01-25 22:48 ` Dave Chinner
2012-01-25 23:03 ` Andreas Dilger
2012-01-27 0:19 ` Dave Chinner
2012-01-27 14:27 ` Tao Ma
2012-01-29 22:07 ` Dave Chinner
2012-01-30 22:50 ` Andreas Dilger
2012-01-30 23:52 ` Ted Ts'o
2012-02-01 3:57 ` Dave Chinner
2012-01-30 20:41 ` Eric Sandeen [this message]
2012-01-30 22:52 ` 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=4F270091.3050000@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@dilger.ca \
--cc=hao.bigrat@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).