From: Coly Li <i@coly.li>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Andreas Dilger <adilger@dilger.ca>,
Andreas Dilger <adilger@whamcloud.com>,
linux-ext4 development <linux-ext4@vger.kernel.org>,
Alex Zhuravlev <bzzz@whamcloud.com>, Tao Ma <tm@tao.ma>,
"hao.bigrat@gmail.com" <hao.bigrat@gmail.com>
Subject: Re: bigalloc and max file size
Date: Tue, 01 Nov 2011 20:22:17 +0800 [thread overview]
Message-ID: <4EAFE479.3050304@coly.li> (raw)
In-Reply-To: <898A7160-25A8-44BA-B08B-C8FADC87F8EA@MIT.EDU>
On 2011年11月01日 19:47, Theodore Tso Wrote:
>
> On Oct 31, 2011, at 9:10 PM, Coly Li wrote:
>>
>>> I assume the issue then is you
>>> want to minimize the number of extents, limited by the 15-bit extent
>>> length field?
>> Not only extents, but also minimize inode table blocks, bitmap blocks.
>
>
> So this makes no sense to me. Bigalloc doesn't have any effect on the number of inode table blocks, and while it certainly shrinks the number block allocation bitmap blocks, changing the extent tree format has no effect on the number of bitmap blocks.
>
In mkfs.ext4, with -N 16, there are still much more inodes allocated, because for each block group there has to be some
inode blocks to be allocated. For bigalloc, same file system size may have less block groups, which results less inode
blocks.
>>>
>>> What cluster size are you thinking about?
>> Currently we test 1MB cluster size. The extreme ideal configuration (of one use case) is, there is only one block group
>> on the whole file system. (In this use case) we are willing to try biggest possible cluster size if we are able to.
>
> This is where you have a single file which is nearly as big as the entire file system? In that case, why are you using an ext4 file system at all? Why not just use a raw partition instead, plus an auxiliary partition for the smaller files?
>
To make management simple and easy, sys-admin team trends to use on-hand Linux tools to manage the data, a raw disk
format is the last choice. Yes, your suggestion make senses, while there is open source project using raw disk for the
similar purpose, but it takes quit long time to deploy another stable system to online servers ...
> I'm not being critical; I'm just trying to understand your use case and constraints.
>
I try to explain in one line why we are interested on bigalloc: try best to minimize all kinds of metadata space, both
on disk and in memory.
Thanks.
--
Coly Li
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-11-01 12:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 23:36 bigalloc and max file size Andreas Dilger
2011-10-27 1:05 ` Tao Ma
2011-10-27 6:35 ` Theodore Tso
[not found] ` <EB03FF23-73BC-4FDC-B991-5EB3FEEB8DAE@whamcloud.com>
2011-10-27 11:48 ` Theodore Tso
[not found] ` <97D9C5CC-0F22-4BC7-BDFA-7781D33CA7F3@whamcloud.com>
2011-10-27 21:42 ` Theodore Tso
2011-10-28 3:31 ` Tao Ma
2011-10-31 10:15 ` Theodore Tso
2011-10-31 10:27 ` Tao Ma
2011-10-31 18:53 ` Sunil Mushran
2011-10-31 19:09 ` Andreas Dilger
2011-10-31 20:00 ` Ted Ts'o
2011-11-01 4:06 ` Tao Ma
2011-10-30 5:37 ` Coly Li
2011-10-30 19:49 ` Theodore Tso
2011-10-31 9:35 ` Coly Li
2011-10-31 10:22 ` Theodore Tso
2011-10-31 16:08 ` Andreas Dilger
2011-10-31 16:22 ` Ted Ts'o
2011-10-31 17:39 ` Coly Li
2011-10-31 19:38 ` Ted Ts'o
2011-11-01 1:10 ` Coly Li
2011-11-01 11:47 ` Theodore Tso
2011-11-01 12:22 ` Coly Li [this message]
2011-10-31 16:34 ` 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=4EAFE479.3050304@coly.li \
--to=i@coly.li \
--cc=adilger@dilger.ca \
--cc=adilger@whamcloud.com \
--cc=bzzz@whamcloud.com \
--cc=hao.bigrat@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tm@tao.ma \
--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).