Hi,
On Wed, May 15, 2002 at 11:28:57AM -0400, Thomas Bassel wrote:
> I appreciate the explanation, Stephen.
>
> hope I'm not belaboring... but
> are you saying that running fsck will
> detect/correct any bit on the disk if it
> spontaneously changes for whatever reason?
No, of course not! If you flip a bit in the data contents of some
file, fsck can't undo that. The file looks perfectly consistent ---
it just contains something other than what it is supposed to change.
All fsck can do is to repair inconsistencies in the filesystem
metadata. For example, if an allocation bitmap bit is flipped, then
fsck can reconstruct the correct bitmap by looking through the file
mapping information to see which blocks are really in use. However,
if that file mapping metadata itself is wrong, then there's no way
fsck can tell the difference between that and a bitmap error --- all
it knows is that the two don't agree with each other. fsck will make
things consistent, but not necessarily by repairing the original
fault.
> it seems to me that this condition would not
> be found in an ext2 situation either until the
> 20 reboot/6 month period passes, or something
> funny is happening on the server.
That's right, but ext2 and ext3 both have mechanism to detect certain
inconsistencies at run time. For example, if the allocation bitmaps
get out of sync and there is a block in use which is marked free, then
if you try to delete the file that that block belongs to, the fs will
detect that you are deleting a block whose allocation bit is already
unset. In such cases, the filesystem can set a flag in the superblock
indicating that an error was found, so a fsck will be forced on the
next reboot. You can also tell the fs either to panic immedately on
such an error, or to abort the fs and remount it readonly to prevent
further damage ("man tune2fs" and "man mount" to see how to control
that behaviour.)
Cheers,
Stephen
