From: Theodore Ts'o <tytso@mit.edu>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: high write latency bug in ext3 / jbd in 3.4
Date: Mon, 13 Jan 2014 17:52:19 -0500 [thread overview]
Message-ID: <20140113225219.GD11207@thunk.org> (raw)
In-Reply-To: <20140113211610.GE1214@kvack.org>
On Mon, Jan 13, 2014 at 04:16:10PM -0500, Benjamin LaHaise wrote:
>
> I'm leaning towards doing this. The main reason for not doing so was
> primarily that a few of the tweaks that I had been made to ext3 would
> have to be ported to ext4. Thankfully, I think we're still in an early
> enough stage of release that I should be able to do so. The changes
> are pretty specific, mostly allocator tweaks to improve the on-disk
> layout for our specific use-case.
We have been thinking about making some changes to the block
allocator, so I'd be interested in hearing what tweaks you made and a
bit more about your use case that drove the need for these allocator
tweaks.
> I had hoped to use ext4, but the recommended fsck after changing the
> various feature bits is a non-starter during our upgrade process (a 22
> minute outage isn't acceptable).
You can move to ext4 without necessarily using those features which
require an fsck after the upgrade process. That's hwo we handled the
upgrade to ext4 at Google. New disks were formatted using ext4, but
for legacy file systems, we enabled extents feature (maybe one or two
other ones, but that was the main one) and then remounted those file
systems using ext4. We called file systems which were upgraded in
this way "ext2-as-ext4", and our benchmarking indicated that for our
workload, that "ext2-as-ext4" got roughly half the performance gained
when comparing file systems still using ext2 with newly formated file
systems using ext4.
Given that file systems on a server got reformatted when it needs some
kind of hardware repairs, betewen hardware refresh and disks getting
reformatted as part of the refresh, the percentage of file systems
running in "ext2-as-ext4" dropped fairly quickly.
Mike Rubin gave a presentation about this two years ago at the LF
Collab Summit that went into a lot more detail about how ext4 was
adopted by Google. That presentation is available here:
http://www.youtube.com/watch?v=Wp5Ehw7ByuU
Cheers,
- Ted
next prev parent reply other threads:[~2014-01-13 22:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 20:13 high write latency bug in ext3 / jbd in 3.4 Benjamin LaHaise
2014-01-13 21:01 ` Andreas Dilger
2014-01-13 21:16 ` Benjamin LaHaise
2014-01-13 21:39 ` Eric Sandeen
2014-01-13 22:52 ` Theodore Ts'o [this message]
2014-01-14 0:55 ` Andreas Dilger
2014-01-14 1:01 ` Eric Sandeen
2014-01-14 1:21 ` Benjamin LaHaise
2014-01-14 3:52 ` Theodore Ts'o
2014-01-27 23:55 ` Jan Kara
2014-01-28 16:06 ` Benjamin LaHaise
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=20140113225219.GD11207@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=bcrl@kvack.org \
--cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).