Hi,
On Tue, May 16, 2000 at 04:55:52PM +0200, Sasi Peter wrote:
> On Tue, 16 May 2000, Michael H. Warfield wrote:
>
> Not only have I written, that no user processes were running, but also,
> that afet a reboot, an e2fsck -f did find a REAL LOT of inconsistencies!
No. After the reboot, e2fsck just found the inconsistencies that I'd
expect it to find after a reboot in which there were files unlinked
but still open.
What happens when that happens is that the first pass of e2fsck finds
the orphaned inode, and detects it as a deleted inode (there are no
directory references to it and the link count is zero) which hasn't
actually been deleted yet (the delete time --- dtime --- is non-zero).
That's the first error you saw.
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.
--Stephen
-
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