[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FS corruption; HTREE-related?

On Mon, Oct 07, 2002 at 06:18:00AM +0000, JP Howard wrote:
> Some file in the directory was supposed to be deleted. It looked by the
> directory entry, but got it wrong somehow, but in such a way that it
> removed
> the wrong file, but removed the right directory entry. So I can see the
> problem being produced like this:
> 1. I have a directory with 2 files, 'a' and 'b'
> 2. I delete 'a'
> 3. It removes the 'a' from the directory list, but for some reason,
>    deletes the inode for 'b'
> Would this result in what we're seeing, namely that 'b' appears in the
> directory, but it's inode says that it's deleted and free?

That's a possible theory; but in order for that to be true, not only
would you be left with a directory entry pointing at a deleted inode,
you would also have an inode with either no directory entry pointed at
it, or if the inode was hard-linked, an incorrect reference count.  

So the e2fsck transcript should also have showed an unreferenced inode
which it would offer to move to the lost+found directory, or an
indication of some inode with an incorrect reference count.  (i.e.,
the inode refcount indcates that there should be 3 directory entries
pointing at it, but there are only two).

Do you remember seeing anything like that?  If so, knowledge of what
that other inode was would be very helpful, since it would indicate
that your theory was very likely correct, as well as what the identity
of the file that was intended to be deleted.

I confess to being a little skeptical towards this theory, since the
HTREE doesn't change the code which searches the directory entries in
a particular directory block.  It simply uses the hash tree to narrow
down the search so that only the correct directory block is searched,
instead of needing to search every single block in the directory.
Also, the binding between a particular directory/name pair is bound in
a particular dcache entry, and that lookup is done *before* we get to
the unlink code.  If that binding were incorrect, normal lookups would
also be failing by associating filenames with incorrect inodes, and
that would presumably get very obvious very quickly.  

Hmm..... unless there's a bug where very rarely, the inode pointer in
the dcache structure is getting corrupted by the unlink code.  That's
the only way I could see that your theory might be happening in
practice.  Anyway, I'll take a look at that.  In the meantime, could
you confirm whether or not you saw any other traces in the e2fsck
transcript that would look like an inode was missing a directory entry
pointing to it?

						- Ted

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]