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 _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
