Messages in this thread | | | Date | Thu, 20 Jan 2000 08:10:08 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: ext2_free_blocks (fwd) |
| |
Date: Thu, 20 Jan 2000 11:46:11 +0100 (MET) From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
>>>[..] Since fsck -f didn't find any problems, it was probably your >>>hardware hiccuping and returning the wrong block when ext2 tried to read >>in an indirect block. [..] >> >>The corrupted metadata block is been freed before fsck had a chance to run >>and once the metadata block become an unused block all returned fine. >> >How do you know that? It's a plausible scenario, but only if someone >deleted the file containing the bad indrect block before running fsck.
The kernel would've spit a bunch of "freeing block outside datazone" in that case.
Very true. I usually recommend that people, when they see that error, to immediately reboot and run fsck, since to not do that risks further filesystem corruption. I'm going to be submitting patches which changes these from ext2_warnings to ext2_errors, so that (depending on how your filesystem's error-behaviour has been set using tune2fs) this will result in either a panic/reboot, remounting the filesystem read-only, or ignoring the error. Right now, ignoring it is the only thing that happens, and people can get their filesystems pretty badly toasted as a result.
I've seen a number of cases where such errors are reported, but then when you run fsck, the filesystem is clean. This *usually* means a hardware problem where the wrong block was transferred by the hardware (say a bad cable caused one or two bits to be flipped in the block address). It can mean a severe buffer cache problem or some other kernel bug, although usually we get a lot more complaints if that is the case. What I find is that people usually are completely unwilling to believe that their hardware might be at fault, which is why I usually mention this first as a possibility. It is important for us as kernel developers to try to see patterns in the bug reports, and consider the possibility that it might be our fault, of course.
- Ted
- 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/
| |