Guest section DW wrote:
>
> From dledford@redhat.com Sat Apr 24 18:36:31 1999
>
> Guest section DW wrote (about extended translation for aic7xxx):
>
> > 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.
> >
> > 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.
But I do not thank you.
Unfortunately I have a certain visibility as fdisk maintainer,
author of the Large-Disk HOWTO, answerer of lots of geometry questions
on the net. It happens regularly that I have to send people a kernel
patch because the kernel does the wrong thing in their situation.
You are creating more of such cases. I am unhappy about that.
Maybe you do not realize how time-consuming it is to find out
what the user's problem is and then to construct a kernel patch
that probably will help him. It is a thousand times faster to say
"try the `extended' boot parameter".
> 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
You say: if the user happens to use certain versions of Windows NT
on an Alpha then you don't care what happens. Too bad. I do care.
... 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.
Ah, Doug - you are angry and start writing nonsense.
0. LILO and fdisk want to know H (the number of heads) and S (the number
of sectors per track) and the total disk capacity.
1. Now you come and look at a partition table.
In the great majority of the cases you can read off H and S from
the ending (c,h,s) of the first nonempty partition, since you will
usually have H=h+1 and S=s. There is no way to derive the number
of cylinders or the total capacity from the partition table.
Since BIOSes usually do not tell you what the number of cylinders is
because they are afraid of mentioning numbers above 1024, the only
sensible thing is to set C = capacity/(H*S).
There is nothing to compare to see whether you did right.
It is fairly common to have partition tables that do not cover
the entire disk.
(And all this is assuming a DOS-style partition table, but people
also use other kinds of partition tables, look at genhd.c and see
what variation Linux supports today; trying to look at sector 0
will certainly fail for such other partition table types.)
> 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.
... 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.
Why is that? Linux does not use the geometry part of the partition table,
so Linux will work fine. Fdisk will also work fine, only warn you that
some partitions do not end at a cylinder boundary, which may give problems
with DOS-type software and Partition Magic. LILO will also work fine
as long as the driver returns the geometry that the BIOS will use at
boot time.
Now you change the driver and make it report a geometry derived from the
disk. LILO does not work anymore, but that is easily fixed by inserting
the `linear' keyword in lilo.config. (But now LILO loses the ability of
warning you for stuff past the 1024 cylinder boundary, and some people will
find at the next reboot that they have a system that doesnt boot anymore.)
Fdisk does not warn anymore, but that does not mean things have improved:
the warning still applies, and DOS-type software can still destroy your
disk - the driver has only hidden the potential problems.
In short: letting the SCSI driver look at a partition table only has
a cosmetic effect: certain fdisk warnings go away.
You have destroyed information, and no longer reveal to fdisk/LILO
what geometry the BIOS will use for this disk, and accomplished nothing.
Some people will have problems because they also have DOS on this disk.
What do I have to tell them? Fdisk has to rewrite the geometry fields
of the partition table. But using what geometry? The kernel no longer
tells us, so I have to mail such people a kernel patch, removing the
driver part that looks at the partition table.
I hope you understand my unhappiness.
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/