From: Andreas Schlick <schlick@lavabit.com>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: [PATCH 0/2] Fix wrong name_len and file_type in intermediate htree nodes
Date: Sun, 30 Aug 2009 16:56:40 +0200 [thread overview]
Message-ID: <200908301656.40866.schlick@lavabit.com> (raw)
Hello,
while testing the dirshrink patch, I found that sometimes intermediate htree
nodes end up with their fake_dirent's name_len and file_type not being zero.
e2fsck will then consider the htree to be corrupted as it doesn't recognise
that these blocks contain dx_nodes.
As far as I understand it, this happens sometimes when ext4_dx_add_entry() has
to create a new index node and calls ext4_append(). In the end ext4_getblk()
is called and it might get a buffer that has BH_Uptodate set, causing
ext4_getblk() to not zero it out and leave the old content intact.
I can reproduce this with plain linux-2.6.30.5. To produce this I use a nearly
full filesystem and continuously create new files in one directory while
removing other directories/files at the same time.
Do I understand it correctly, that it happens when the newly allocated block
(for the new index node) was very recently used by another file/directory, so
that it is still in the buffer cache? But it surprises me that it doesn't
happen more often.
Andreas Schlick
next reply other threads:[~2009-08-30 15:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-30 14:56 Andreas Schlick [this message]
2009-08-30 14:57 ` [PATCH 1/2] ext4: Always set dx_node's fake_dirent explicitly Andreas Schlick
2009-08-30 14:58 ` [PATCH 2/2] ext3: " Andreas Schlick
2009-09-11 3:19 ` [PATCH 1/2] ext4: " Theodore Tso
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=200908301656.40866.schlick@lavabit.com \
--to=schlick@lavabit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.