NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: disk geometry (i386/amd64)



On 9/10/2018 11:03 PM, Michael van Elst wrote:
On Mon, Sep 10, 2018 at 05:37:53PM -0700, Don NetBSD 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.

The disklabel might be the only thing that you can count on.

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. As I said, the disklabel is ignored for the raw partition.

Yes, but if I *examine* the label, there is nothing that "ignored by the raw
partition" can do to give me valid parameter values.  I.e., the rest of the
label BESIDES the 'd' partition.

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?

The driver might not support that request.

OK.

DISKINFO appears to not be "confused" by changes to the in-kernel label
DIOCGDISKINFO is what 'drvctl -p' will show you and gets data from the driver.

Yes.

I've not yet tried this with the DINFO ioctl.
DIOCGDINFO gets you a copy of the in-kernel disklabel.

Which is what disklabel(8) reports!

DIOCGSECTORSIZE gets you the size of a disk sector from the driver.
DIOCGMEDIASIZE gets you the number of disk sectors from the driver.

these were added for NetBSD-8 but also pulled up to NetBSD-7.1 (not
NetBSD-7.0) for compatibility with FreeBSD and to simplify programs
to get these values.

Hmmm... my bad.  The machine I built at work runs 7.1 -- but the box I have
been using here, at home, to explore this stuff is still at 6.1.5.  I will
have to move my code over to the box at work.

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

It is probed and scanned for things like the disklabel or other partitioning
information and the wedge driver attaches to allow access by filesystems
as the disklabel does not support large disks.

But all that will do is generate diagnostic messages, not interfere with my
use of the physical device via the 'd' partition.  I don't really care if my
actions leave the medium in a state that NetBSD can't understand (as a NORMAL
drive) as it will never be asked to "understand" it.

OK.  So:
- manually insert drive
- rescan the scsibus
- start the device in question
- DIOCGDISKINFO to get size
- DIOCiforgot to unlock label portion
- read/write /dev/rsd#d
- DIOCCACHESYNC to flush pending writes
- stop the device
- manually remove drive

(I guess I'll have to see how I can "wait on start" and "wait on stop"...
synchronous calls?)

Thanks!  Maybe I'll bring the server home and code this over the weekend.


Home | Main Index | Thread Index | Old Index