It is very possible the case. I am doing experiment now. This happened
very randomly. Same script randomly produce the bug. Each time the problem
block happen at a different place. I just can't consistently reproduce
I am doing some experiment now.
On Sat, Sep 28, 2002 at 11:27:49AM -0600, Andreas Dilger wrote:
> On Sep 28, 2002 10:13 -0400, Theodore Ts'o wrote:
> > The nature of the corruption is that a directory entry of size 8
> > (which is enough room for a zero-length name) is left in the
> > directory. This is harmless, but it should never happen normally, and
> > so the ext3 sanity-checking code flags it as an error. With this
> > patch, e2fsck is much smarter about salvaging corrupt directories, and
> > so it can do so without causing any directory entries to be lost.
> > (This corrupted, too-small directory entry appears at the beginning of
> > the directory block, which is another reason why I strongly suspect
> > the dx_split code.)
> One idea I just had but don't have time to investigate (babysitting
> both kids today) is if the do_split() code is creating a hash entry
> for unused dir entries (i.e. inode == 0 or name_len == 0). If that
> is the case, then it could explain the presence of this short entry.
> Cheers, Andreas
> Andreas Dilger
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Ext2-devel mailing list
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/