Date: Mon, 04 Nov 2002 19:02:59 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: John Hay <jhay@icomtek.csir.co.za> Cc: n_hibma@van-laarhoven.org (Nick Hibma), imp@bsdimp.com, current@FreeBSD.ORG Subject: Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken Message-ID: <1869.1036432979@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 04 Nov 2002 19:19:57 %2B0200." <200211041719.gA4HJvaG014484@zibbi.icomtek.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200211041719.gA4HJvaG014484@zibbi.icomtek.csir.co.za>, John Hay wri
tes:
>>
>> Let's work on the 'proper' solution first.
>>
>> What SCSI commands are suitable for getting the geometry, generically
>> on a device?
>
>Hmmm, I made an interesting discovery. I searched through some of the
>scsi drivers, sys/dev/{aha|ahb|aic*|sym}, looking for XPT_CALC_GEOMETRY
>and they all fake the geometry. :-/
I noticed this too recently when studying PC98 related disk code.
Solaris on the other hand, pokes some random mode-page which contains
some numbers which may, but more likely may not, have any relationship
to the real hardwares format. Few if any drives have constant number
of sectors per track these days.
At least our scsi code never returns degenerate numbers.
Anyway, what I really wanted to say is that the reason I put the
"FW" in the name of the DIOCGFW{SECTORS,HEADS} ioctls was that at
this time and date, the only possible utility of such archaic values
are to avoid breaking stupid firmware.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1869.1036432979>