Messages in this thread |  | | Date | Thu, 13 Jun 1996 21:10:29 -0700 | From | "Leonard N. Zubkoff" <> | Subject | My SCSI HD has 34 heads, not 255... |
| |
Date: Thu, 13 Jun 1996 14:51:01 -0400 (EDT) From: Tom Zerucha <root@mars.ceddec.com>
The problem (and the reason I created the AUTO_BIOSP patch) is that many low-level drivers don't implement the bios_param function correctly. For example, my laptop docking station has an aha152x chip BUT NO BIOS. The default behavior of the adaptec drivers is to remap >1Gb disks to the extended partitioning scheme if there is no bios present. The linux aha152x driver didn't follow this earlier. I would get the same fdisk confusion messages if I didn't use the AUTO_BIOSP patch.
That may be the problem, but the AUTO_BIOSP patch was an ill-advised solution that should never have been included in the kernel. When it first came out, I publicly questioned its advisability, but no one responded and I didn't take further action until there was a definite report of problems, at which time I sent Linus a patch to remove it. In retrospect, I wish I'd noticed the severity of the danger and had it removed sooner.
There is only one purpose for the Linux kernel knowing anything whatsoever about cylinder/head/sector geometry mapping for SCSI disks: compatibility with the non-Linux world. This compatibility issue takes two forms: (1) since the system BIOS (i.e. probably the SCSI host adapter's BIOS) must be able to locate the kernel for booting, LILO must be able to compute BIOS-compatible C/H/S locations for the files it needs access to; and (2) Linux FDISK needs the geometry information to be able to create and modify partition tables that are compatible with other operating systems. Other than in these two cases, Linux will happily run with a partition table whose C/H/S geometry does not match the BIOS, and won't even notice that there is a discrepancy.
It is very important that any low level SCSI driver provide a correct disk geometry as the disk would be seen by the BIOS. Without this, neither LILO nor FDISK can do their jobs properly. In the rare situation where one needs to partition a disk with a geometry that is not what the BIOS would use (such as creating a disk using host adapter A that's intended to be moved to host adapter B), both LILO and FDISK provide mechanisms for experts to override the geometry provided by the driver. It might be advisable for LILO and FDISK to provide expert options for automatically adopting whatever geometry is already deducible from the partition table, but this is not the kernel's job.
If for some reason the geometry that will be used by the BIOS cannot be determined, or if the host adapter does not have a BIOS, then it may be appropriate to use the existing geometry as a default. But this is a decision that must be made by individual drivers where appropriate, and should certainly not apply across all included drivers regardless of their own wishes. The AUTO_BIOSP patch provided an easy trap for the unwary.
I usually do the FDISK under DOS, and if that doesn't agree with whatever the low-level driver in the kernel implements, you get the messages from linux fdisk which gets totally confused. Has anyone bothered to check the current and historical windows, dos, and os/2 drivers for what they think the partition mapping schemes should be?
DOS FDISK gets its idea of the geometry from the BIOS, so if the Linux driver does not return the same geometry, then it is broken and should be fixed.
When I move my hard drive between systems, each SCSI card can implement a totally different partitioning scheme. So I will take a chance of destroying any SCSI disk when I move it across systems, which I have to do since my laptop, and various desktops have different cards. Forget using removable media (e.g. Iomega Jaz drives and large capacity optical) unless you want to take chances.
That is indeed a risk, but only if you use LILO or FDISK on host adapters with different translations. As long as you merely access the partitions, you shouldn't encounter problems since it is the starting sector and sector count that actually define the partition's location and size from Linux' perspective. If you aren't trying to boot from the drive, how would you even notice the mismatched geometry unless you run LILO or FDISK? It's only the HDIO_GETGEO ioctl that's affected.
AUTO_BIOSP solved this by looking at the partition sector or determining it, and it appears scsicam is also a standard. I probably should have made the help text clearer, since it was only intended to be used if fdisk under Linux looked strange after fdisking under DOS/WIN/etc., or if you needed to move disks across systems.
SCSICAM is a standard that's only supported by some host adapter BIOS'. If the host adapter will use SCSICAM, then the driver whould be made aware of this.
[snip snip]
If my idea is badly broken, what do you suggest I do since I have two systems that return the WRONG partition mapping (I used DOS to fdisk) and move the hard drive (an AV with CD writer) across several systems?
If you really need to use LILO or FDISK, they both provide options to handle this case. If you are just accessing file systems, where's the problem?
You would be correct if two things were true: 1. the low level drivers always provided the correct mapping (I carefully verified Qlogic isa/vlb/pcmcia, and the in2000.c - the aha1542 has problems when you turn the bios off and use a large disk, most others simply copied the default mapping and never verified it). 2. No one ever changed SCSI cards or moved disks across systems.
If they don't, then they should be fixed. The HDIO_GETGEO ioctl should return the correct geometry as viewed by the BIOS. If user programs like LILO and FDISK have a reason to do something different, they may ignore the HDIO_GETGEO result and look at the partition table themselves. But there is no reason for the kernel to do so.
You don't like my fix. I would like to hear your idea or if anyone else out there has a better one. I still need to move hard drives across systems with different controllers.
If someone has evidence that moving drives between different controllers is impossible I will revisit the question.
Leonard
|  |