FYI: Multiple OSes, partition tables, lossage

[Benjamin Scott]

On Sun, 2 Jan 2005, at 7:52pm, bill at bfccomputing.com wrote:
>> Programs (like parted) which previously depended on the kernel to provide
>> good answers got hosed.  This could easily render a legacy OS unbootable.
> 
> That's a good reminder to check versions of code you depend on before you
> do something potentially destructive. ... The parted guys may not have
> expected kernel 2.6 to change much, but certainly kernel 5.2 might treat
> partition tables differently.

  Well, in this case, it's not a simple case of obsolete software on a much
more modern system.  It's modern software (parted) on a modern system
(Linux), dealing with a bad hardware design layered with horribly broken
extensions.  Really, the whole geometry thing was a mess before.  This
latest complication has only made things worse.  But it *did* make things
worse, and I feel we could have done without that.

  The specific problem stems from the fact that a given individual drive can
have more then one "geometry".  IDE drives report a geometry to the host
when asked.  This geometry is invented by the drive's onboard electronics,
since the actual, internal, *physical* geometry is non-uniform.  I will call
this the "IDE geometry".

  Now, to work around certain esoteric limits, the IDE geometry will often
be translated by the host (mainboard or IDE adapter BIOS, generally) into a
*different* invented geometry.  It mainly involves decreasing the number of
cylinders while increasing the number of heads, IIRC.  I will call this the
"translated geometry".

  The partition table generally uses the translated geometry.  Prior to
kernel 2.6.something, the Linux kernel generally reported the translated
geometry when asked.  Then, in kernel 2.6.mumble, it was changed to report
the "IDE geometry" instead.

  (The actual situation is even worse, but the above will do.)

  This meant that the kernel effectively scrambled the disk for anything
trying to work both within and outside of Linux, and that trusted the kernel
to give consistent answers.

  I, along with many others, feel that (1) a function that has such a
critical impact should not be changed without a lot of prior warning, (2)
rather then changing the answer given, the kernel should return an error
(such as ENOSYS).

  I also question the validity of the basic assumption that the problem is
somebody else's.  I also dislike the attitude that "We're the only OS that
matters".  That's something I usually get from a legacy OS, not Linux.  
These are subjective, non-technical opinions, however.  The ideas in the
previous paragraph are general best practices.

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |