Re: disk geometry change

Doug Ledford (dledford@redhat.com)
Sat, 24 Apr 1999 23:04:09 -0400


Guest section DW wrote:
>
> From dledford@redhat.com Sat Apr 24 18:36:31 1999
>
> Guest section DW wrote (about extended translation for aic7xxx):
>
> > This was true for 2.0.* and is still somewhat true for 2.2.6
> > but the precise conditions have changed (and became messier).
> > Two important changes are:
> >
> > For 2.0.36 giving boot parameters "aic7xxx=extended" would always
> > give you an extended translation. For 2.2.6 this will only work
> > if the driver finds no SEEPROM, but will be ignored otherwise.
> >
> > For 2.0.36, if the driver did not find a SEEPROM it would
> > always give you an extended translation.
> > For 2.2.6, if the driver did not find a SEEPROM it will
> > only give you an extended translation if you asked for it.
> >
> > I do not know whether this change was intentional - it seems
> > to me that a driver should do what the user asks in an explicit
> > boot parameter.
>
> That latest driver allows the SEEPROM to override the user setting since
> it makes no sense to not have them match.
>
> Roughly speaking I agree - it makes no sense in 98% of the cases.
> Unfortunately the remaining 2% writes to me with problems and complaints.

No, it never makes sense. If you are going to use the BIOS defined
geometry at all, then you should never vary from what the BIOS is
using. If someone actually thinks that it does help then they need to
learn to set their system up properly.

> I think the driver should never ignore the explicitly given wish
> of the user. This user will only start supplying boot time parameters
> when the default does not work. So, it never makes sense to ignore
> boot parameters.

Not every user that uses boot parameters has a clear understanding of
what those parameters do no matter how much documentation I write. I'll
take the word of the SEEPROM config over the boot option when available
thank you.

> However, it *only* does this when there are no partitions on
> the device, the latest code will always take the geometry used
> in the partition table over its own geometry.
>
> I am very unhappy with such behaviour.
>
> It is a myth that it is possible to derive the geometry used
> from the partition table. These days there seems to be a
> fairly standard convention that partitions should end on a
> cylinder boundary, but many fdisk versions will allow the
> user to select arbitrary partition boundaries. Not only Linux
> fdisk, but for example also certain Windows NT versions for
> the Alpha do this.

So. If the user is experienced enough to go around tinkering with start
and end cylinders on their disk, then they get what they get and they
can solve the problem. But, more directly to your complaint, it's easy
enough to tell when the partition sizes you deduce from the disk don't
match the capacity (or even come close) and fail on the partition based
geometry detection. If you get fairly close, then you know you did the
right thing. There's no myth about it except in your mind.

> And what does "the geometry" mean? You know very well that this
> is not a concept that makes sense for SCSI disks. So, it is only
> a fiction that makes fdisk and LILO happy. And for fdisk it is
> pure fiction, it really makes no difference what garbage you write
> in the geometry field as long as you have a Linux-only system.
> But for LILO it has some real significance: it is the geometry
> that will allow successful interaction with the BIOS at boot time.

Which is the intent and purpose behind the "linear" option. To use the
geometry in LILO instead of the linear sectors is as broken as anything
else you have claimed is broken.

> The SCSI driver may know what the on-board BIOS of the card will do.
> But what the BIOS will do is surely not dependent on disk contents.
> So any SCSI driver that returns a geometry deduced from looking at
> the disk is *broken*. LILO and fdisk read the partition table
> themselves. They do not need anybody else to tell them what is there.

Have you even thought about what I wrote? It doesn't sound like you
have. Take your spanky new disk and install linux. Guess what, there
isn't a partition table around so you use the BIOS defined geometry.
The next time you boot, you get the geometry from the partition table
you just created, and it is the *same* as the boot geometry since the
disk wasn't partitioned before. Nothing broken there. Case 2, you
install windows on your disk before you install linux. Fine, but the
Windows partition uses the same geometry as the BIOS, so when you boot
linux you get the same geometry from the partition table as you would
from the BIOS. Case 3, you have a disk that was formatted on an NCR (or
other) SCSI controller and it uses some stupid ass geometry layout. You
put it in on the aic7xxx controller. If we don't get the geometry from
the partition table, the disk is useless until it is repartitioned and
reformatted. If we do get the geometry from the partition table, then
it works like a champ, but you have to have the "linear" option in your
lilo.conf file to get around the different geometry the BIOS uses. So
what does this boil down to, if you install a disk fresh on this driver,
then it acts effectively the same as before. If you migrate a disk from
a different controller, it actually works now. What's the one possible
failure mode? People that dick around with their start/end boundaries
on partitions. Do I care? Not a whole lot. If they have enough
knowledge to change those values, they can certainly work around
anything here. Especially since it will default back to BIOS values
when the partition values turn out obviously wrong so it is unlikely
this mode will ever occur.

-- 
  Doug Ledford   <dledford@redhat.com>
   Opinions expressed are my own, but
      they should be everybody's.

- 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/