From: Ted Ts'o <tytso@mit.edu>
To: Tao Ma <tm@tao.ma>
Cc: Andreas Dilger <adilger@whamcloud.com>,
linux-ext4 development <linux-ext4@vger.kernel.org>,
Alex Zhuravlev <bzzz@whamcloud.com>,
"hao.bigrat@gmail.com" <hao.bigrat@gmail.com>
Subject: Re: bigalloc and max file size
Date: Mon, 31 Oct 2011 16:00:53 -0400 [thread overview]
Message-ID: <20111031200053.GI16825@thunk.org> (raw)
In-Reply-To: <4EAE780D.3090005@tao.ma>
On Mon, Oct 31, 2011 at 06:27:25PM +0800, Tao Ma wrote:
> In the new bigalloc case if chunk size=64k, and with the linux-3.0
> source, every file will be allocated a chunk, but they aren't contiguous
> if we only write the 1st 4k bytes. In this case, writeback and the block
> layer below can't merge all the requests sent by ext4. And in our test
> case, the total io will be around 20000. While with the cluster size, we
> have to zero the whole cluster. From the upper point of view. we have to
> write more bytes. But from the block layer, the write is contiguous and
> it can merge them to be a big one. In our test, it will only do around
> 2000 ios. So it helps the test case.
This is test case then where there are lot of sub-64k files, and so
the system administrator would be ill-advised to use a 64k bigalloc
cluster size in the first place. So don't really consider that a
strong argument; in fact, if the block device is a SSD or a
thin-provisioned device with an allocation size smaller than the
cluster size, the behaviour you describe would in fact be detrimental,
not a benefit.
In the case of a hard drive where seeks are expensive relative to
small writes, this is something which we could do (zero out the whole
cluster) with the current bigalloc file system format. I could
imagine trying to turn this on automatically with a hueristic, but
since we can't know the underlying allocation size of a
thin-provisioned block device, that would be tricky at best...
Regards,
- Ted
next prev parent reply other threads:[~2011-10-31 20:00 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 [this message]
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
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=20111031200053.GI16825@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@whamcloud.com \
--cc=bzzz@whamcloud.com \
--cc=hao.bigrat@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tm@tao.ma \
/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).