From owner-freebsd-questions@FreeBSD.ORG Mon Sep 11 06:42:25 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40C7E16A403 for ; Mon, 11 Sep 2006 06:42:25 +0000 (UTC) (envelope-from jdow@earthlink.net) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD4AB43D53 for ; Mon, 11 Sep 2006 06:42:24 +0000 (GMT) (envelope-from jdow@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tiFznL54BLONPtJ7eU4juDa1TgJNCZh4FsWXbArLhjlTOmPQa483r3MX5NDn0HXv; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [71.116.130.69] (helo=Wednesday) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GMfUo-00056B-PM for freebsd-questions@freebsd.org; Mon, 11 Sep 2006 02:42:19 -0400 Message-ID: <001d01c6d56d$6d4cd060$0225a8c0@Wednesday> From: "jdow" To: References: <20060909201151.30355.qmail@web32715.mail.mud.yahoo.com><089801c6d484$4812a1b0$0225a8c0@Wednesday> <200609101908.25757.ihilt@bluebottle.com> Date: Sun, 10 Sep 2006 23:42:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-ELNK-Trace: bb89ecdb26a8f9f24d2b10475b5711207accd2cb983a4b7508236975ca2dd6b6c26936b653ac4aac350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.116.130.69 Subject: Re: Origin of hard drive parameters X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2006 06:42:25 -0000 From: "Ian Graeme Hilt" > > 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