From: Howard Cochran <hcochran@lexmark.com>
To: linux-ext4@vger.kernel.org
Subject: Kernel thread to zero itables for lazy_itable_init?
Date: Wed, 10 Jun 2009 18:41:22 -0400 [thread overview]
Message-ID: <4A303692.3010104@lpdev.prtdev.lexmark.com> (raw)
Greetings.
What is the status of the code to start a background kernel thread to
zero the inode tables when filesystem that was created with mke2fs -E
lazy_itable_init is mounted? All I have found is a patch set posted to
this mailing list back on November 21, 2008 and some discussion of the
implementation, but nothing after that.
Is this effort still alive?
On a related note, from what I have read here, and from looking at the
ext4 kernel code, the filesystem itself never really requires the inode
tables to be zeroed out. The only reason one might want to do that is
so that fsck does not detect false errors.
But, in data=ordered mode, would not marking the inode as allocated in
the bitmap be done in the same journal transaction as populating the
inode on disk (as well as creating a directory entry pointing to it)?
And, unless the journal is broken, then either all that succeeds or none
of it does. So outside of a hardware failure, or data being overwritten
directly on the block device, it's not possible for an "actually in-use"
inode to be marked unallocated in the inode bitmap.
So, I am wondering whether we really need the complexity of a kernel
thread to zero out the itable (or the long delay of doing it during
mke2fs). Instead, would it not be better to modify fsck to ignore
garbage in unallocated inodes, at least for filesystems that have a journal.
Thanks,
Howard Cochran
next reply other threads:[~2009-06-10 22:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-10 22:41 Howard Cochran [this message]
2009-06-11 5:37 ` Kernel thread to zero itables for lazy_itable_init? 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=4A303692.3010104@lpdev.prtdev.lexmark.com \
--to=hcochran@lexmark.com \
--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).