From: Lukas Czerner <lczerner@redhat.com>
To: linux-ext4@vger.kernel.org
Cc: rwheeler@redhat.com, sandeen@redhat.com, jack@suse.cz,
tytso@mit.edu, adilger@dilger.ca, lczerner@redhat.com
Subject: [PATCH 0/3] Lazy itable initialization for Ext4
Date: Fri, 20 Aug 2010 19:51:41 +0200 [thread overview]
Message-ID: <1282326704-14838-1-git-send-email-lczerner@redhat.com> (raw)
Hi, all
I am presenting you initial version of my lazy inode table initialization
code for Ext4. The patch set consist of three patches. The first one adds
helper function for blkdev_issue_zeroout called sb_issue_zeroout as I am
using it to zero out inode table. Second patch adds new pair of mount
options (inititable/noinititable), so you can enable or disable this
feature. In default it is off (noinititable), so in order to try the new
code you should moutn the fs like this:
mount -o noinititable /dev/sda /mnt/
And finally the third patch adds the inode table initialization code
itself. Thread initialization was heavily inspired by nilfs2 segctord.
DESCRIPTION:
When file system is mounted with "inititable" mount option, new thread
(called itableinitd) is created. This thread walks through allocation
groups searching for the group with not yet initialized inode table.
When such a group is found it write zeroes through whole inode table and
put itself into sleep for defined number of seconds to not disturb other
ongoing I/O. This is repeated until it walks through every allocation group
then the itableinitd thread is stopped.
When regular inode allocation are going too fast, there is a chance that
it hits the group with uninitialized inode table sooner than the
itableinitd thread. In that case it just initializes the itable for
itself the same way that itableinitd thread would do eventually. To
prevent race conditions, each group is protected by the mutex.
For now, there is no way to control itableinitd thread. It would probably be
nice to have more control over how often it is woken up maybe through
sysfs interface, or we can add some more logic into it in order to be more
I/O sensitive and not put too much stress on already stressed system.
However, this may be counterproductive, because we want inode table to be
initialized before regular inode allocator hits it.
Personally I think, we should create some kind of sysfs interface
(/sys/fs/ext4/<device>/itable_init_interval ?) so the user space can watch
the system and control itableinitd wake-up interval for itself.
This is the first version of patch set and it received very limited testing
so far. In order to try this patch you should do the following (aside
compiling kernel with this patch)
1. Make Ext4 fs with lazy_itable_init extended option.
mke2fs -T ext4 -E lazy_itable_init=1 <device>
2. Mount this file system with inititable mount option
mount -o inititable <device> <dir>
Any comments are more than welcomed.
Thanks!
-Lukas
---
[PATCH 1/3] Add helper function for blkdev_issue_zeroout
[PATCH 2/3] Add inititable/noinititable mount options for ext4
[PATCH 3/3] Add inode table initialization code into Ext4
fs/ext4/ext4.h | 66 ++++++++++++
fs/ext4/ialloc.c | 75 +++++++++++++
fs/ext4/super.c | 274 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/blkdev.h | 8 ++
4 files changed, 423 insertions(+), 0 deletions(-)
next reply other threads:[~2010-08-20 17:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-20 17:51 Lukas Czerner [this message]
2010-08-20 17:51 ` [PATCH 1/3] Add helper function for blkdev_issue_zeroout Lukas Czerner
2010-08-20 17:51 ` [PATCH 2/3] Add inititable/noinititable mount options for ext4 Lukas Czerner
2010-08-20 17:51 ` [PATCH 3/3] Add inode table initialization code into Ext4 Lukas Czerner
2010-08-23 22:59 ` Andreas Dilger
2010-08-24 9:01 ` Lukas Czerner
2010-08-25 6:08 ` Andreas Dilger
2010-08-25 13:00 ` Lukas Czerner
2010-08-24 12:38 ` Ric Wheeler
2010-08-26 11:03 ` Peng Tao
2010-08-26 12:14 ` Lukas Czerner
2010-08-26 14:15 ` Peng Tao
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=1282326704-14838-1-git-send-email-lczerner@redhat.com \
--to=lczerner@redhat.com \
--cc=adilger@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=sandeen@redhat.com \
--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).