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