All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.