Re: disk geometry (i386/amd64)

[Don NetBSD <netbsd-embedded%gmx.com@localhost>]

[should I be "reply all" or just the list?  I guess a matter of personal
preferences?]

On 9/10/2018 10:08 PM, Robert Elz wrote:
>    | So, I can use the 'd' partition to access the medium (after unlocking the label
>    | portion).  But, I can't count on anything else "displayed" by disklabel.  And,
>    | I can't count on even the displayed values for the d partition if something
>    | tinkers with the in-kernel label before I get a peek at it.
>
> That's all correct.
>
>    | > The raw partition allows this.
>    |
>    | Again, as long as nothing else tinkers with the in-kernel copy of the disklabel
>    | before I look at it.
>
> No, regardless of that.   Access to the raw partition ignores whatever is
> in the label, always.   If not, there'd be no way to fix a badly broken label
> (as in, if the label said that the size of the raw partition was 0 sectors.)

Please reread the initial exchange (reproduced below, for convenience):

----8<----
>> Further, I wanted to know that I could query the OS for details as to the
>> size of the medium (sector size and number of sectors).
>> on the media to have been preinitialized *or* requiring it to be "initialized"
>> prior to my access.  (I *won't* be writing a "disklabel" onto the medium but
>> will be altering much/all of its contents, otherwise)
>
> The raw partition allows this.

Again, as long as nothing else tinkers with the in-kernel copy of the disklabel
before I look at it.
----8<----

I.e., if something has tinkered with the in-kernel copy of the disk label,
then disklabel(8) will report those tinkered values.  So, I could NOT use
disklabel(8)'s output -- or anything else that reports the in-kernel
values -- to get an accurate description of ANY portion of the ACTUAL
"size of the medium (sector size and number of sectors)".  In the absence of
other mechanisms (e.g., the DIOCGDISKINFO ioctl), my only way to determine
the actual size of the medium would be to explore the 'd' partition with
seeks to ever increasing offsets.

For example, I can readily create a situation where the contents of
the portion of the physical medium wherein the label normally resides,
the output of disklabel(8) and the actual characteristics of the physical
device are all *different* from each other.

By way of proof:  a drive that has been zeroed (so, the label portion
contains nothing but zeroes); a disklabel(8) that has been *edited* to
completely bogus values and "saved" (or, anything else that alters the
in-kernel label); the actual disk, itself.

My goal is a reliable way of exposing what the "disk, itself" says!

(which appears to be DIOCGDISKINFO, but not DIOCGDINFO)

>    | > - DIOCGDISKINFO (using proplib!)
>    | > - fall back to DIOCGDINFO if that failed
>    |
>    | Why would it have failed?
>
> if it were not implemented I think was the intent there.   That is, so the
> code could work on various different versions of the system (be reasonably
> portable) - and possibly also because (this I am not sure about) not all
> drivers might implement the new method (yet).

Ah, OK.  So, if I verify this for the sd(4) driver on a particular OS
version/port, then I need never concern myself that some particular *drive*
may fail to yield valid data?  I.e., if the ioctl fails, I can panic()?

>    | [I also need to query the SMART structures and other disk parameters
>    | but I can workaround that]
>
> SMART (what a name for something so simplistic) is available too.   No idea how,
> but there are commands that get at it (and make changes) so it is clearly possible.

I think only via wd(4)?

>    | I want the same sort of access -- but to the disk controller.
>
> Disks are a little more more uniform and have a better structured command
> set than the parallel port, so it is possible that there may be some
> interference from the driver that simply knows that some things are
> possible, and others are not - even if you disagree.
>
> But just reading/writing arbitrary blocks on the drive should be possible