> 
> > However, I still have a couple of questions.  Can someone check me on
> > my assumptions:
> 

A lot of this information is covered in the FAQ, and is still current.

> > 1) The disk has a real, honest to God geometry.  That is, it really
> > is organized into a certain number of cyls, has a certain number of
> > heads, and has a certain number of sectors per track.  (I hope at
> > least _this_ is true :) )
> 
> Sorry. :-)
> 
> The disk probably does have "real" cylinder and head counts; they
> correspond to physical reality.  But if the disk is at all modern, it
> probably does not have any single sectors-per-track number; on almost
> any disk nowadays the sector count varies with the cylinder number
> (outer cylinders have more magnetic material per disk revolution
> available, so they store more bits there).
> 
> If you're using IDE/EIDE, I _think_ addressing demands that the disk
> pretend to have a fixed sectors-per-track value, but if it does I'm
> quite sure it's just pretense.  (A SCSI disk is just a big linear array
> of sectors anyway; the only pretense involved there is what the OS
> imposes on itself - like geometry information in disk labels.)
> 

IDE disks have a 'reported real' geometry which corresponds the ST-506
standard.  There is no (easy) way to get the 'actual' drive geometry 
from the drive once it is connected to an IDE controller.  Once the BIOS
resets it (usually using LBA) you can get yet another disk geometry.

This (the reported geometry) is what you need to use.

> > 2) The controller talks to the physical disk using these parameters.
> 
> > 3) The BIOS provides geometry translation so braindead operating
> > systems can access the disk.
> 
> I think these are true, but it's rather out of my area of expertise.
> 

The BIOS sets the parameters in the controller and the controller
provides the translation.  From this point of view, it is more like the
SCSI model.

> > It seems to me that all three of these can't be true.  If they are,
> > why can't an operating system update eliminate all the geometry
> > translation nonsense?
> 
> As I understand it, compatability with old OS versions demands that the
> BIOS do the fakery; with the BIOS doing that, OSes have to deal with
> it.
> 

The BIOS just directs it.  The controller is doing the fakery.

> > Secondly, why is it that 
> 
> > 1) On a label pasted on the top of the disk, it says 1416 cyls, 16
> > heads, 63 spt
> > 1.5) www.wdc.com says the Caviar AC2700 has 1416/16/63
> > 2) The BIOS says 1416/16/63
> > 3) NetBSD says 1416/16/63 when it asks the drive
> > 4) pfdisk claims 707/32/63
> 
> > What's pfdisk know that the manufacturer doesn't?
> 
> Probably, I would say, that some OSes have trouble with cylinder counts
> over 1023 (or is it over 1024?).  So someone is lying - maybe the BIOS
> is fudging the values returned by the call pfdisk makes?  Or by pfdisk
> do you not mean some DOS-level program that would use BIOS calls to
> access the disk?  That's pure guesswork....

Tell pfdisk to use 1023/16/63 and press on.  DOS will be happy and
NetBSD will ignore the disklabel and get the geometry from the 'native'
geometry.  Since the track size is correct, the info on the disk should
be OK.

-- 
Dave Burgess                   Network Engineer - Nebraska On-Ramp, Inc.
*bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean there isn't someone that 
doesn't want to do it...."