> It should actually assume that such inodes are corrupt, and either just
> delete them at e2fsck time, or at least clear the "bad" parts of the inode
> before sticking it in lost+found.
I had this happen to me once before. I did something bad, and when I
started my machine up again, I got a couple of files in lost+found. I
couldn't delete two of them.
I posted my trouble here, and I got many of the same hints I've seen given
this time around.
What just made me think, is you just said that e2fsck should clean up this
problem before putting it in lost+found. That is probally a good idea.
But it was also half way to my solution. e2fsck did know there was
something wrong with the inodes, but since it marked the disk clean the
first time it was run it wouldn't bother looking over the disk upon
farther reboots. I wasn't comfortable with figuring out how to use
debugfs, so I just left the 2 bad files there. Until I did something
else silly and another fsck was forced. Upon being run the second time
e2fsck did notice something out of order and fixed up the files so I could
delete them.
So yes, e2fsck probally should have noticed the problem the first time
through and not written a funky file to lost+found. But this might be a
possible solution for the orginal poster of the message. Just force a
check right now and see if it gets fixed.
-Chris
-- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/