From: Andreas Dilger <adilger.kernel@dilger.ca>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: Amir Goldstein <amir73il@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
"Darrick J. Wong" <djwong@us.ibm.com>,
Sunil Mushran <sunil.mushran@oracle.com>,
Andi Kleen <andi@firstfloor.org>, Mingming Cao <cmm@us.ibm.com>,
Joel Becker <jlbec@evilplan.org>,
linux-ext4@vger.kernel.org, Coly Li <colyli@gmail.com>
Subject: Re: [PATCH] libext2fs: reserve exclude bitmap fields in group descriptor
Date: Fri, 16 Sep 2011 14:22:06 -0600 [thread overview]
Message-ID: <1D75A7AC-0707-4952-B765-7BBC307E6CE0@dilger.ca> (raw)
In-Reply-To: <CAGBYx2YR6o0HG3xrvNJC6mp8d3Eh+3R_j_JHkdHXKFtp3p7ubA@mail.gmail.com>
On 2011-09-16, at 5:43 AM, Yongqiang Yang wrote:
> On Fri, Sep 16, 2011 at 2:45 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> No, I am not sure this is accurate.
>> I think after we over viewed the e2fsprogs snapshots patch set, you
>> has 2 observations:
>> 1. the largest part (in lines of code) of the e2fsprogs snapshot patch set
>> is related to the exclude inode/bitmap code.
>> 2. it reminded you of resize inode too much and you didn't like that
>> 3. There was also the issue of whether or not to allow the removal of
>> the exclude inode/bitmap
>> and then re-allocation would not be in optimal layout
>>
>> In retrospect, after Yongqiang has implemented the alternative exclude
>> bitmap patch set
>> for e2fsprogs, I can say:
>> 1. The alternative patch set is not smaller
>> 2. It is a lot more elegant and deals with correct layout of exclude
>> bitmap (next to block bitmap)
>> 3. It will be able to deal with 64bit fs (unlike exclude/resize inode)
>> and 64bit resize
>>
>> Yongqiang, do you have anything else to add to the exclude inode vs.
>> group desc issue?
>
> Nope, regarding resize group desc is better than exclude inode. For
> meta_bg, group desc is much more welcome.
I'm not dead-set on using the exclude inode. I was just wondering if there
was a clear benefit to doing so. I'm OK with having 16-bit checksums for
the inode bitmaps for now, and possibly changing mke2fs to always creating
ext4 filesystems with the 64bit feature. Always specifying 64bit for ext4
filesystems will allow larger checksums, and has the added benefit of
facilitating resize from below 2^32 blocks to over 2^32 blocks as well.
One minor drawback is the size of the s_group_desc array doubles in size, so
the allocation needs to be larger (handled in newer kernels by ext4_kvmalloc())
and it needs more space on disk. At 16TB the group descriptor table would
use 8MB instead of 4MB, and at 256TB the group descriptor table would fill
the whole 128MB of the first group, where we HAVE to use META_BG because the
second group is also filled with the backup GDT.
Cheers, Andreas
next prev parent reply other threads:[~2011-09-16 20:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 6:50 [PATCH] libext2fs: reserve exclude bitmap fields in group descriptor Amir Goldstein
2011-09-15 10:06 ` Andreas Dilger
2011-09-15 14:03 ` Amir Goldstein
2011-09-15 14:21 ` Ted Ts'o
2011-09-15 13:16 ` Ted Ts'o
2011-09-15 13:47 ` Amir Goldstein
2011-09-15 19:08 ` Andreas Dilger
2011-09-15 21:57 ` Ted Ts'o
2011-09-16 6:45 ` Amir Goldstein
2011-09-16 11:43 ` Yongqiang Yang
2011-09-16 20:22 ` Andreas Dilger [this message]
2011-09-16 6:55 ` Amir Goldstein
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=1D75A7AC-0707-4952-B765-7BBC307E6CE0@dilger.ca \
--to=adilger.kernel@dilger.ca \
--cc=amir73il@gmail.com \
--cc=andi@firstfloor.org \
--cc=cmm@us.ibm.com \
--cc=colyli@gmail.com \
--cc=djwong@us.ibm.com \
--cc=jlbec@evilplan.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sunil.mushran@oracle.com \
--cc=tytso@mit.edu \
--cc=xiaoqiangnk@gmail.com \
/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