Date: Mon, 11 Sep 2006 20:04:04 -0700 From: "jdow" <jdow@earthlink.net> To: <freebsd-questions@freebsd.org> Subject: Re: Origin of hard drive parameters Message-ID: <027401c6d618$1f6e7690$0225a8c0@Wednesday> References: <20060909201151.30355.qmail@web32715.mail.mud.yahoo.com><200609101908.25757.ihilt@bluebottle.com><001d01c6d56d$6d4cd060$0225a8c0@Wednesday> <200609112111.56000.ihilt@bluebottle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Ian Graeme Hilt" <ihilt@bluebottle.com>
> On Monday 11 September 2006 2:42 am, jdow wrote:
>> From: "Ian Graeme Hilt" <ihilt@bluebottle.com>
>>
>> > May I point out that I was not interested in CHS alone. My focus was the
>> > origin of the hard drives parameters i.e. geometry, which is the subject
>> > of > discussion. From this discussion and other sources I have learned
>> > that CHS, > as you say, is arbitrary when referring to modern drives. To
>> > be specific, drives adhering to ATA/ATAPI Specification 6 and later.
>> > ATA/ATAPI Spec. 5 and earlier used CHS mode for representing hard drive
>> > capacity. The reason I am > interested in this topic is partially because
>> > of my "idle curiosity". I'm the type of person interested in the
>> > challenge of answering questions. The questions, "How does the BIOS
>> > automatically detect correct values for hard disks?" and, "Where is this
>> > information stored?" have been stuck in my head > for at least 6 months.
>> > No amount of searching the web provided me with
>> > satisfactory results. I tried a few tests of my own, all of which failed
>> > to > answer my questions. So, I decided to appeal to the
>> > FreeBSD-questions mailing list. Mainly because I have found useful
>> > answers to other questions here. The other part of my reason is that one
>> > of my coworkers thought this information was stored on the platters of
>> > the hard drive. I thought differently but I could not _prove_ it.
>>
>> Good reason. And the information is indeed stored on the platters of
>> the hard disks in a place you cannot read directly.
>
> How do you know this is true?
A friend of mine, who goes or went by the ID "scsi", worked at Micropolis
then Hitachi then Maxtor then Seagate. I watched her put the operating
code on the disks. I also have written and used a MODE SELECT/MODE
SENSE utility that allowed me to alter the drive's formatting. I KNOW
that data was not downloaded to the drive by the OS. <cough> I had
adequate source for the Amiga OS by that time to know. {^_-} The OS
knew how to read the data it needed off the drive. And so did the
RDPrepX utility I wrote. If it was not stored on the drive NOT in
one of the active user sectors then it was PFM that the drive worked
at all. (I still have a fondness for the Amiga Rigid Disk Blocks
format. If I can fix the BSD machine's "Chinese Capacitor Syndrom"
and get it back on line I plan to make sure BSD has the ability to
at least read the Amiga RDBs. The filesystem is another ballgame,
though. That may already be covered. But most people get the RDB
parsing wrong one way or another, particularly for 2k physical block
size magneto-optical stoage.)
>> It is easier for
>> me to refer to SCSI than to ATA. With SCSI the operating code for the
>> disk is stored on the disk. What comes up at first is enough SCSI to
>> say "I'm a disk; and, I'm not ready." When you issue ReadCapacity,
>> Mode Sense, and Inquiry commands you are accessing data stored on the
>> same reserved sectors as the disk's operating code. Special diagnositic
>> commands allow the operating code to be modified. The "Mode Select"
>> command allows you to reconfigure the disk's geometry. This takes
>> effect after you next low level format the drive if you have no other
>> intervening commands. This allows you to alter the spare blocks and
>> cylinders on the disk as well as configure most other operating
>> parameters. These are stored where operating systems normally cannot
>> see them with normal read/write commands.
>>
>> So your coworker is correct, it is stored on the drive
>
> Actually, he was arguing this information was stored on the platters of the > hard
> drive. I was arguing it could be stored in a chip on the hard drive
> which I'm thinking of as the CMOS for a motherboard.
I can verify that the drives at the time I was working on them did not
have nvram on the drives. And you cannot store it on the motherboard
and still have the disks portable, which simple experiments can prove.
The earliest drives were VERY parts deficient. As they progressed the
companies got smart and figured "We have this EXCELLENT non-volatile
storage quite handy to us so we'll store the firmware with the parameters
on the platters and simply start counting block zero after this data
space." It works. I was astonished, twice (once at the cleverness and
second at my stupidity for not thinking of it before hand), when scsi
told me about it. Gayle really digs disk drive internals. Erm, and by
accident I latched on to a copy of the Micropolis code for one of the
last disks they made. "It's in there." And I've NEVER shared it. 'T
would not be right to do that.
>> and barring nvram on the drive it is stored on the actual platters.
>
> This is exactly my point. There is cause for reasonable doubt that it isn't > stored on
> the platters.
See my "Duh" reaction above. Why spend MORE money for nvram when there
is a nice rotating non-volatile store quite handy. It can bootstrap
nicely several ways.
1) Read parameters so it knows when to step heads from block zero or
zero and one. Then load the operating firmware, switch to it, and
run normally.
2) Read the first few blocks to read a firmware bootloader then load
parameters into the firmware bootloader. Finally proceed as in 1.
This requires less EPROM storage than option 1.
>> >> As for storing it - read block zero of the disk.
>> >> Be DAMN careful not to WRITE to block zero. And if you DO write
>> >> to block zero at about the time I quit doing such low level stuff
>> >> and moved to other things there were several SCSI hard disk
>> >> manufacturers using code that had a defect such that if you wrote
>> >> more than one disk block starting at block 0 the whole disk was
>> >> toast until you did a fresh low level format on it. One sincerely
>> >> hopes THAT defect is gone these days.)
>> >>
>> >> {O.O} Joanne
>> >
>> > Reading through ATA/ATAPI -7 has helped me rephrase my questions into
>> > one: When the command READ NATIVE MAX ADDRESS is issued to the device,
>> > from where is this information returned?
>>
>> It may be cached somewhere for quick returns.
>
> Yes, but it also may be stored in the hard drive's CMOS.
No-such-aminal. Costs to much when you have all those gigabytes of
rotating storage so handy. {^_-} I was being facetious mentioning the
concept of nvram.
>> There are tools for tuning
>> disk performance for both ATA and SCSI disks that can alter the operating
>> parameters. Some options read OS cached values. Others dig down and issue
>> the 'standard' query commands and read the actual values off the disk. The
>> disk is the final arbiter, in modern terms. When doing the configuration
>> utility that became arguably the most popular one for the Amiga I ran
>> across some small number of hard disks that returned off by 1 values for
>> size. (Micropolis was one offender at one time.) And I also ran across
>> drives delivered with only the first few megabytes formatted. So I built
>> into the configuration utility an actual search for the last readable
>> block. I used the lesser of that value and the value the drive declared
>> to Read Capacity commands. At least the formats it generated were safe.
>> (I think it was either Maxtor or CDC/Seagate that had the partially
>> formatted drives escape from their factory.)
>>
>
> It is possible the the factory settings for the capacity of a hard drive
> are
> stored in a chip, which I'm calling CMOS, on the circuit board attached to
> the hard drive. This information is then modified and saved to an
> inaccessible portion of the hard drive's platters or to another area of the > hard
> drive's CMOS using the ATA command SET MAX ADDRESS, SET MAX ADDRESS
> EXT
> for 48 bit mode, or similar command. Then when the command IDENTIFY DEVICE
> is
> sent to the drive, it reports a smaller size to the caller.
It is not cost effective.
>> I hope this answers questions enough so that the next question is more
>> obvious. (And in retrospect - the drive is the only thing that knows
>> the precise formatting parameters. So it is quite logical that the
>> original source for the size data is the drive itself. This is not
>> always, in my experience, a constant for all revisions of the same
>> model of drive.)
>>
>> {^_^} Joanne
>
> --
> ~ Ian Graeme Hilt
{^_^} Joanne
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?027401c6d618$1f6e7690$0225a8c0>