Re: Origin of hard drive parameters
- From: Ian Graeme Hilt <ihilt@xxxxxxxxxxxxxx>
- Date: Mon, 11 Sep 2006 21:11:55 -0400
On Monday 11 September 2006 2:42 am, jdow wrote:
From: "Ian Graeme Hilt" <ihilt@xxxxxxxxxxxxxx>
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?
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.
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.
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.
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.
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
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: Origin of hard drive parameters
- From: jdow
- Re: Origin of hard drive parameters
- References:
- Re: Origin of hard drive parameters
- From: stheg olloydson
- Re: Origin of hard drive parameters
- From: Ian Graeme Hilt
- Re: Origin of hard drive parameters
- From: jdow
- Re: Origin of hard drive parameters
- Prev by Date: Re: Upgrade server from i386 -> amd64 kernel ...
- Next by Date: Re: Upgrade server from i386 -> amd64 kernel ...
- Previous by thread: Re: Origin of hard drive parameters
- Next by thread: Re: Origin of hard drive parameters
- Index(es):
Relevant Pages
|
