Stephen C. Tweedie wrote:
> e2fsck then marks the inode as deleted. Of course, the file's contents
> don't get removed from disk until the file is actually deleted, so now
> we have destroyed the inode, but the disk blocks it owned are still
> marked as being in use on the filesystem. e2fsck then gives you warnings
> about block and inode bitmaps being wrong, as the bitmaps think the
> file was still present. It then fixes that by marking the blocks as
> free. Finally, you get bitmap count errors, because we've just freed
> those blocks, so the superblock free block counts need to be updated.
>
> The "errors" you saw just look like the normal repairs e2fsck has
> to do to deal with a file which hasn't been closed before being
> deleted.
Perhaps the real bug here is too much error output from e2fsck.
Mere orphan files should give one message "deleting orphan file --
system shut down while file in use?" or similar.
All the bitmaps for _those_ files are supposed to be set -- perhaps
there should even be bitmap difference messages if those files' bitmaps
are _not_ set.
That way, if there are more serious errors you'd see it in the messages.
Besides, a big check can sometimes spend a long time simply scrolling
the console :-) (Text mode scrolling is amazingly slow on some systems).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:13 EST