lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.031 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site