Re: disk geometry (i386/amd64)

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

On 9/9/2018 10:26 PM, Michael van Elst wrote:
> On Sun, Sep 09, 2018 at 05:49:15PM -0700, Don NetBSD wrote:
> > On 9/9/2018 1:52 PM, Michael van Elst wrote:
> > > On Sun, Sep 09, 2018 at 12:08:14PM -0700, Don NetBSD wrote:
> > > > Said another way, are these "in-kernel" values (which no longer reflect
> > > > the physical medium) ever reported in other system calls/ioctls/etc.
> > > > INSTEAD of the "real" values?
> > >
> > > What is 'real' ? Start with the assumption that there is no way to know
> > > the real data and that the disklabel is the method to record such
> > > information. 'real' is then what you wrote into the disklabel.
> >
> > The disk has a real size that can be queried from the actual device.
>
> disklabel predates that. At that time you knew the data from looking at
> the device with your eyes or reading the documentation. Then you wrote
> the data as disklabel to a known disk sector.

Yes.  The early IDE drives required the controller to tell *them* what
their geometry was.

> This didn't really change, except that something like the disklabel
> tool will now get the data by querying the drive and then writing it
> to the disklabel sector. Other software (mostly) gets the information
> then from the disklabel.

But, the system knows the geometry (sectors + sector size) from the device
probe -- even if disklabel is never invoked.  This is the data that I want
without the "system" deciding to "color" it (or alter it!) for me.

E.g., in our products, we talk directly to the drive and don't require
something else to do this on our behalf.

> > I wanted assurance that I could access the 'd' partition and be assured
> > access to the entire medium, regardless as to what MIGHT have been encountered
> > in the sectors of the medium that NetBSD examines in search of a label.
>
> That is always true. If there is no disklabel on-disk, you will get a
> generated one, if there is a disklabel, you will get that. But for the
> raw partition the offset and size are ignored.

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.

(In theory, *I* should be the only thing dealing with that disk)

> -> find the raw partition with sysctl
> -> just access it.
>
> > 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.

> > I had planned on DIOCGDINFO -- with all the caveats mentioned
> > above.  Perhaps DIOCGDISKINFO would be a better choice?
>
> Old (but not too old) code needed to:
>
> - DIOCGDISKINFO (using proplib!)
> - fall back to DIOCGDINFO if that failed

Why would it have failed?

DISKINFO appears to not be "confused" by changes to the in-kernel label
(edit disk size, etc. using disklabel(8); verify the changes persist
beyond disklabel(8) invocations; run drvctl as a wrapper for the DISKINFO
ioctl to verify the original drive values remain intact).

I've not yet tried this with the DINFO ioctl.

(It may be easier for me to just start at the device probe and work my
way *up* into the system than to attempt to dig down from above!)

> - optionally use DIOCGWEDGEINFO to support partition devices ("wedges")

No wedges.  No partitions.  No filesystem.  Disk is just "blocks of persistent
memory".  I just need to know how many, how large they are and be able to
access ALL of them -- regardless of what the disk may have "experienced"
prior to my "seeing" it.

[I also need to query the SMART structures and other disk parameters
but I can workaround that]

> > There's no confusion as no one/nothing looks at the disk besides my software.
>
> The OS will look at the disk as soon as it is attached.

Only to probe it.  The drive is never mounted.  Never labeled.  Never
"anything" -- other than the actions I will be taking (or, others staff
operating under similar constraints).

E.g., if I attached something to a "printer port" and it wasn't a printer, the
OS wouldn't care.  Yet, would still let me use that hardware to talk to
said device.

I want the same sort of access -- but to the disk controller.

> > But, I'd be concerned about pulling a drive that was still *spinning*.
> > atactl(8) doesn't seem to work with sd(4) devices.  I'll have to see if
> > drvctl -d spins the drive down as it is disconnected (and maybe a timeout
> > to ensure the operator doesn't remove the drive before its had a chance
> > to spin down sufficiently)
>
> For sd devices you can try 'scsictl ... stop'.

Ah, OK.

I'll start digging through the sources to verify what is happening at
the physical interface in each of these cases.