Messages in this thread | | | Date | Fri, 15 Jan 1999 02:17:38 +0100 (MET) | From | (Guest section DW) | Subject | Re: (un)corrupted ext2 partitions |
| |
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Date: Thu, 14 Jan 1999 21:08:29 +0100 From: Marc Espie <espie@quatramaran.ens.fr>
What I also don't know is what should be done when you get an incoherent view of the disk. Trust the linux-side ? Sounded like the simplest way to do things... I don't see how panicing at such an early point would help, for instance.
Panic'ing certainly doesn't help, but printing huge amounts of warnings is definitely in order. :-)
Maybe not even that. When Linux boots, the disks can in principle be in arbitrary state. Maybe they just came from some other machine, with some operating system none of us has ever heard of. Or maybe the disk was just tested by writing random patterns to it and reading them back.
So, nothing is wrong when there is garbage on the disk. (I have not checked recently - there have been times where you could crash a kernel by having a bad extended partition (starting at a negative or very large block number, which would make the driver unhappy) - but the kernel takes notice of the partition table, mentions what it saw in the boot messages and otherwise does nothing with the disk contents.) Disk contents first really acquires a meaning when one does a mount.
The rc scripts might also want to be rewritten to test for this case and avoid mounting things read-write if there's known conflicts in partition table.
At first sight I do not really see what kind of conflicts you could be thinking of. (Perhaps a BSD whole-disk filesystem that on block 0 happens to have a pattern that can be read as a DOS-type partition table? In principle the kernel needs for each disk, or at least for the disk containing the root partition, a partitiontabletype= keyword, just like it also needs a rootfilesystemtype= command line keyword. On the other hand, I have not yet heard about cases where the former really is required.)
Andries
- 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/
| |