Re: disk geometry (i386/amd64)

[Michael van Elst <mlelstv%serpens.de@localhost>]

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.

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.


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

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


> > - use opendisk() to get a filedescriptor.
> > - use ioctl(...,DIOCGSECTORSIZE,...) to get the byte size of a disk sectors.
> > - use ioctl(...,DIOCGMEDIASIZE,...) to get the number of disk sectors.
> 
> A quick grep of the sources (7.1/amd64) don't turn up any hits for these
> ioctls.

Indeed, that's netbsd-8 and later. As I said, the native interface was
limited and new interfaces were added.


> 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
- optionally use DIOCGWEDGEINFO to support partition devices ("wedges")


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


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


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."