Messages in this thread |  | | Date | Fri, 14 Jun 1996 09:45:17 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Re: My SCSI HD has 34 heads, not 255... |
| |
Date: Fri, 14 Jun 1996 08:59:24 -0700 (PDT) From: Thomas E Zerucha <zerucha@shell.portal.com>
Is it the kernel's job to return some random number, or to return the correct geometery?
It is the kernel's job to return the correct geometry as it would be seen by the system BIOS. If the driver is unable to deduce this, using a geometry that may be inferred from the partition table might be reasonable; even better still would be returning 0/0/0 as "unknown". This will force a warning from FDISK.
Which of my four systems should I run the FDISK on? I will want to access the same disks under DOS (which I can do with Adaptec and Qlogic since they both use the Adaptec Extended mapping standard). This would limit me to having to format any >1GB drive on my Qlogic at home (or now with my laptop unless aha152x goes back to the pre 1.3.98 version). I only know this because I have investigated it. Running the linux fdisk to create a new linux partition anywhere else would destroy the DOS partition
Not if you correctly set the C/H/S values in FDISK. If you want Linux FDISK to be smarter or better documented, I strongly support that idea. There's no reason it couldn't prompt the user whenever it detects mismatched geometry between HDIO_GETGEO and the partition table, and allow the user to select the "incorrect" existing geometry if desired. Similarly for LILO if necessary. That would lower the degree of "expertness" involved.
These drivers (and I checked out lots of others that simply did a cut-paste and only do 32/64 and many truncate at 1GB) were broken in 1.2, weren't fixed in 1.3, and are still buggy in 2.0. Which release will contain verified, fully working drivers? 2.2? 3.0? 10.0?
Obviously I cannot answer that. But unresponsive driver authors is not a reason to include unnecessary and ill advised code in the kernel. If you've determined the correct implementation for a specific host adapter, submitted a patch, and a driver author ignores you, that is a social problem and can be dealt with. Driver bug fixes are certainly welcome, though the driver's author should always be given an opportunity to comment upon or rewrite a fix if they aren't happy with it.
Your solution is to have any user with problems to become experts with lilo and fdisk, assuming they can determine if their particular driver is broken, and figure out what the correct values actually are.
Any user facing this problem will have to acquire a certain degree of knowledge to understand what will and will not work in a situation with mismatched geometries. I don't see that recompiling the kernel with an EXPERIMENTAL option that hides the genuine issues is a better solution than improvements to FDISK (and possibly LILO) that wouldn't involve recompilation.
I didn't hold that my solution was neat or clean. I only held that it bypassed 95% of the bad drivers (and belonged in the experimental category).
I still don't see the need for it. The only reason geometry determination belongs in the kernel at all is that the SCSI drivers must be consulted for this information. I still believe that FDISK is the correct place for improvements, not a kernel patch that can cause incorrect results to be returned.
Leonard
|  |