Date: Wed, 6 Sep 2006 16:54:32 -0700 From: "jdow" <jdow@earthlink.net> To: <freebsd-questions@freebsd.org> Subject: Re: Origin of hard drive parameters Message-ID: <034201c6d20f$d044a5a0$0225a8c0@Wednesday> References: <890E919AB0857D4A8A52A4AD5E0F0F6221A1C2@msc-server.msc.mcgregor-surmount.com> <945DB39F-ECC9-4872-9F5D-EC45BCD439CE@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Chuck Swiger" <cswiger@mac.com> > On Sep 6, 2006, at 1:06 PM, Hilt, Ian wrote: >>> The hard disk has an on-board controller which answers the ATA >>> "IDENTIFY DEVICE" command with the hard drive parameters used by the >>> BIOS, assuming that the BIOS is operating in the legacy C/H/S mode >>> rather than the newer LBA mode which uses absolute block numbers. >> >> Ok. Maybe the better question is: in either case, C/H/S or LBA mode, >> where are these parameters stored? > > At one time, probably on an EEPROM within the hard drive; nowadays, > probably nowhere-- the drive controller computes some numbers > dynamically depending on whether the C/H/S versus LBA mode jumper is > set, or whether the BIOS makes the extended Int13H call to do LBA > mode (or whatever the exact mechanism there is).... They flat out are not stored anywhere. There is a standard algorithm published by the VESA people, I believe, that provides the data for all SCSI drives and modern IDE/ATA/SATA drives. Inside the drives only one number is normally of interest to the computer operating system, the total number of available blocks on the drive per its current formatting. Spare blocks and cylinders, variable numbers of blocks per track, and various oddball formattings that at LEAST go back as far as the old 20 meg Miniscribe SCSI drives make any CHS that a drive could deliver meaningless. (That old Miniscribe had spares at the end of a cylinder that were to be applied anywhere within the cylinder. Thus there was no constant blocks per track within a cylinder. It had spare tracks scattered around the drive so that you could recover if a whole track was scratched. And so forth. I struggled for some (wasted) time trying to find an optimal CHS geometry I could feed the operating system (Amiga at the time) to speed up disk accesses. That old thing was impervious to optimization. Ever since I've strongly advised people to ignore CHS entirely unless they have a real live ESDI or ST-506 drive in their possession. I suppose it might matter for IDE drives nearly that old. But anything likely to be alive today has CHS as a pure fiction that is not all that particularly useful even at the filesystem optimization levels.) {^_^} Joanne
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?034201c6d20f$d044a5a0$0225a8c0>