Re: Origin of hard drive parameters

[jdow]

From: "Ian Graeme Hilt" <[EMAIL PROTECTED]>


On Monday 11 September 2006 2:42 am, jdow wrote:

From: "Ian Graeme Hilt" <[EMAIL PROTECTED]>

> 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.  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 

Re: Origin of hard drive parameters

[Ian Graeme Hilt]

On Monday 11 September 2006 2:42 am, jdow wrote:
> From: "Ian Graeme Hilt" <[EMAIL PROTECTED]>
>
> > 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 comm

Re: Origin of hard drive parameters

[jdow]

From: "Ian Graeme Hilt" <[EMAIL PROTECTED]>


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. 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 and barring
nvram on the drive it is stored on the actual 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. 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.)

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 


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[Ian Graeme Hilt]

On Saturday 09 September 2006 10:53 pm, jdow wrote:
> From: "stheg olloydson" <[EMAIL PROTECTED]>
>
> > On 9 Sep 2006 14:54:09 - ihilt wrote:
> >>On Wednesday 06 September 2006 7:54 pm, jdow wrote:
> >>> >> Ok. Maybe the better question is: in either case, C/H/S or
> >
> > LBA mode,
> >
> >>> >> where are these parameters stored?
> >>>
> >>> 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.
> >>
> >>Do you know the name of this standard or where I can get it?
> >>
> >>Ian Graeme Hilt
> >
> > Actually, the stardard is created by the T13 Technical Committee
>
> And my idle curiosity would like to know why Ian is interested in
> such an antiquated topic? There is a size limit beyond which CHS 
> simply does not work. The setting of CHS is in practice utterly
> arbitrary. For (many/most?) USB ram disk plugins the T13 standard
> does not apply due to internal ram layout. And so forth.
>
> (Certainly on the Amiga this CHS nonsense made no practical
> difference except on floppy disks or ST-506 based disk drives. And
> in playing with recovering a blown block zero on an Windows machine
> (more than once) I learned that CHS is utterly arbitrary on Windows.
> It is arbitrary with USB ram disk modulo the ram disk's internal
> layout and spares setup. And since large disks for which CHS runs
> out of size abound I imagine there is not a place in the 'n'x world
> where CHS matters. So I am suspecting historical curiosity if
> anything else. 

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. 

> 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?

-- 
~ Ian Graeme Hilt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[jdow]

From: "stheg olloydson" <[EMAIL PROTECTED]>

On 9 Sep 2006 14:54:09 - ihilt wrote:


On Wednesday 06 September 2006 7:54 pm, jdow wrote:


>> Ok. Maybe the better question is: in either case, C/H/S or

LBA mode,

>> where are these parameters stored?



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.


Do you know the name of this standard or where I can get it?

Ian Graeme Hilt


Actually, the stardard is created by the T13 Technical Committee


And my idle curiosity would like to know why Ian is interested in
such an antiquated topic? There is a size limit beyond which CHS
simply does not work. The setting of CHS is in practice utterly
arbitrary. For (many/most?) USB ram disk plugins the T13 standard
does not apply due to internal ram layout. And so forth.

(Certainly on the Amiga this CHS nonsense made no practical
difference except on floppy disks or ST-506 based disk drives. And
in playing with recovering a blown block zero on an Windows machine
(more than once) I learned that CHS is utterly arbitrary on Windows.
It is arbitrary with USB ram disk modulo the ram disk's internal
layout and spares setup. And since large disks for which CHS runs
out of size abound I imagine there is not a place in the 'n'x world
where CHS matters. So I am suspecting historical curiosity if
anything else. 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
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[jdow]

From: "stheg olloydson" <[EMAIL PROTECTED]>


On 9 Sep 2006 14:54:09 - ihilt wrote:


On Wednesday 06 September 2006 7:54 pm, jdow wrote:


>> Ok. Maybe the better question is: in either case, C/H/S or

LBA mode,

>> where are these parameters stored?



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.


Do you know the name of this standard or where I can get it?

Ian Graeme Hilt


Actually, the stardard is created by the T13 Technical Committee
of the InterNational Committee for Information Technology
Standards (INCITS), formerly the Accredited Standards Committee
X3, Information Technology. Its standards are published by ANSI.
The one you are looking for is ANSI INCITS 397-2005 AT
Attachment - 7 with Packet Interface. You can download a pdf
from techstreet.com for $30.00US. Just search for 397-2005. 
You can also get a free copy of a working draft of a standard

withdrawn in 2002, X3.298-1996, from t13.org. While the
information you are looking is unlikely to have changed between
1996 and 2005, you are in a better position to weigh the benefit
to your project of saving $30.00US versus using possibly
horribly wrong information. (It is a _working draft_ from 1996,
after all.)


It's probably cheaper to read the code for the GNU BIOS project
or for things like fdisk. It should be present in both places.

{^_-}
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[stheg olloydson]

On 9 Sep 2006 14:54:09 - ihilt wrote:

>On Wednesday 06 September 2006 7:54 pm, jdow wrote:
>
>> >> Ok. Maybe the better question is: in either case, C/H/S or
LBA mode,
>> >> where are these parameters stored?
>
>> 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.
>
>Do you know the name of this standard or where I can get it?
>
>Ian Graeme Hilt

Actually, the stardard is created by the T13 Technical Committee
of the InterNational Committee for Information Technology
Standards (INCITS), formerly the Accredited Standards Committee
X3, Information Technology. Its standards are published by ANSI.
The one you are looking for is ANSI INCITS 397-2005 AT
Attachment - 7 with Packet Interface. You can download a pdf
from techstreet.com for $30.00US. Just search for 397-2005. 
You can also get a free copy of a working draft of a standard
withdrawn in 2002, X3.298-1996, from t13.org. While the
information you are looking is unlikely to have changed between
1996 and 2005, you are in a better position to weigh the benefit
to your project of saving $30.00US versus using possibly
horribly wrong information. (It is a _working draft_ from 1996,
after all.)

HTH,

stheg 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[Ian Graeme Hilt]

On Wednesday 06 September 2006 7:54 pm, jdow wrote:

> >> Ok. Maybe the better question is: in either case, C/H/S or LBA mode,
> >> where are these parameters stored?

> 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.

Do you know the name of this standard or where I can get it?

Ian Graeme Hilt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[jdow]

From: "Chuck Swiger" <[EMAIL PROTECTED]>


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

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Origin of hard drive parameters

[Hilt, Ian]

> -Original Message-
> From: Chuck Swiger [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, September 06, 2006 4:21 PM
> To: Hilt, Ian
> Cc: freebsd-questions@freebsd.org
> Subject: Re: Origin of hard drive parameters
> 
> 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)
> 
> >> Note that the answer the drive controller gives will normally be a
> >> fabricated geometry which does not have anything to do with the
> >> actual geometry of the physical device, in part because drives
> >> nowadays keep a variable number of sectors per track rather than
> >> using a CAV layout.
> >
> > If CAV == Constant Angular Velocity, I thought this layout stored a
> > variable number of sectors per track, as opposed to CLV which stores
> > data at a constant density over the platters.
> 
> CAV == Constant Angular Velocity.  It's the format used by data CD's  
> which gives less storage space but better random access-- 
> tracks near  
> the center have the same # of sectors as tracks on the 
> outside, which  
> means the outer tracks are spread out more; versus CLV, which stores  
> more data on the outer tracks by slowing down the rotational 
> speed to  
> keep a constant density under the heads.
> 
> -- 
> -Chuck
> 
> 

Thanks for the information, Chuck.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[Chuck Swiger]

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)



Note that the answer the drive controller gives will normally be a
fabricated geometry which does not have anything to do with the
actual geometry of the physical device, in part because drives
nowadays keep a variable number of sectors per track rather than
using a CAV layout.


If CAV == Constant Angular Velocity, I thought this layout stored a
variable number of sectors per track, as opposed to CLV which stores
data at a constant density over the platters.


CAV == Constant Angular Velocity.  It's the format used by data CD's  
which gives less storage space but better random access-- tracks near  
the center have the same # of sectors as tracks on the outside, which  
means the outer tracks are spread out more; versus CLV, which stores  
more data on the outer tracks by slowing down the rotational speed to  
keep a constant density under the heads.


--
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Origin of hard drive parameters

[Hilt, Ian]

> -Original Message-
> From: Chuck Swiger [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, September 06, 2006 2:55 PM
> To: Hilt, Ian
> Cc: freebsd-questions@freebsd.org
> Subject: Re: Origin of hard drive parameters
> 
> On Sep 6, 2006, at 11:40 AM, Hilt, Ian wrote:
> > Basically, I want to know where the BIOS gets the hard drive  
> > parameters
> > when the Drive Type is set to "AUTO" in the BIOS 
> configuration. The  
> > best
> > I've been able to come up with from the internet is an "IDENTIFY"
> > command that purportedly
> > (<http://www.linux.com/howtos/Large-Disk-HOWTO-10.shtml>) gets its
> > information from the "IDE controller". This does not answer my  
> > question
> > completely. Are the parameters returned by the controller hard coded
> > into a chip on the board or are they on the platters of the hard  
> > drive,
> > or neither?
> 
> "Neither" is probably the best answer.
> 
> 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?
   
> Note that the answer the drive controller gives will normally be a  
> fabricated geometry which does not have anything to do with the  
> actual geometry of the physical device, in part because drives  
> nowadays keep a variable number of sectors per track rather than  
> using a CAV layout.
> 

If CAV == Constant Angular Velocity, I thought this layout stored a
variable number of sectors per track, as opposed to CLV which stores
data at a constant density over the platters.

Ian Graeme Hilt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Origin of hard drive parameters

[Chuck Swiger]

On Sep 6, 2006, at 11:40 AM, Hilt, Ian wrote:
Basically, I want to know where the BIOS gets the hard drive  
parameters
when the Drive Type is set to "AUTO" in the BIOS configuration. The  
best

I've been able to come up with from the internet is an "IDENTIFY"
command that purportedly
() gets its
information from the "IDE controller". This does not answer my  
question

completely. Are the parameters returned by the controller hard coded
into a chip on the board or are they on the platters of the hard  
drive,

or neither?


"Neither" is probably the best answer.

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.   
Note that the answer the drive controller gives will normally be a  
fabricated geometry which does not have anything to do with the  
actual geometry of the physical device, in part because drives  
nowadays keep a variable number of sectors per track rather than  
using a CAV layout.


--
-Chuck

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"