Messages in this thread | | | Date | Sun, 25 Apr 1999 15:19:09 +0200 (MET DST) | From | (Guest section DW) | Subject | Re: disk geometry change |
| |
From dledford@redhat.com Sun Apr 25 05:04:21 1999
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/
| |