> 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.
Is it the kernel's job to return some random number, or to return the
correct geometery?
> 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.
Sometimes the Drivers (the DEVICE=XXX.SYS in the config.sys) will override
the BIOS specified (or lack thereof) partition geometery. The low-level
driver isn't likely to scan the config.sys file in the DOS partition to
look for these.
You are correct that it might trap the unwary, but in the later releases
there is not an EXPERIMENTAL setting that could limit it's access, as well
as better help info.
>
> 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.
>
Or from the CONFIG.SYS driver, or the FDISK is a canned program (e.g.
adaptec) designed to force whatever geometery it wants ignoring the
presence or lack of a BIOS, but compatable with the driver files it
installs.
>
> 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.
>
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
>
> 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.
>
It also includes the provision for automatically recoginizing existing
formats. I originally had it as "FORCE_ADAPTEC_EXTENDED_MAPPING" which
every DOS program except the Allways in2000 used.
>
> 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?
>
This functionality is not documented (for fdisk) in the manpage, nor
online. The README.fdisk is probably somewhere on my system. And I do
FDISK on multiple systems, and want it to run under DOS. Disks under DOS
wouldn't transport between Allways in2000 and the adaptecs and qlogics,
but the adaptecs and qlogics would work properly under dos. Only qlogic
would work under linux correctly - both adaptecs were broken and although
I submitted reports and patches where possible most were ignored.
> [stuff about drivers being broken elided]
>
> 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.
>
It would be nice if the aha1542s I had would default to extended bios
mapping so I could do fdisks on those systems, but if you turn the bios
off, they default to the <1GB style (32/64). This is perfectly consistent
and repeatable, and the code was massively changed between 1.2 (where I
had an "if bios disabled" patch) and 2.0 (which I don't understand at all)
and it still does not handle this. After much lobbying I got the aha152x
to follow what the default Adaptec driver does under DOS, but even this
can be overridden with command line options. 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?
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.
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).
zerucha@shell.portal.com ; finger zerucha@jobe.portal.com for PGP key