Re: disk geometry (i386/amd64)

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

On Sun, Sep 09, 2018 at 12:08:14PM -0700, Don NetBSD wrote:

> Which begs the question, why are these presumably immutable parameters
> allowed to be altered in even the in-kernel copy of the label?  Why are
> attempts at altering them (sectors/track, etc.) not ignored completely?

It could be a foreign disklabel that you want to edit, it depends on
the platform what is considered the 'raw partition'.


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


> Obviously, if drvctl(8) can report the "real" values, then they must be
> preserved somewhere besides the in-kernel disklabel.

Modern drives can be queried about the disk geometry. The driver does
this and drvctl can be used to query the values collected by the driver.

The in-kernel disklabel is either generated ("default label") or read
from the on-disk label sector and sanitized a bit.

If you have a large disk, there is usually only a generated label as
the on-disk structure could not describe large (>2TB) disks. The generated
disklabel will show a 2TB sized raw partition and 2TB disk size, but
these values are ignored.


> > Erasing an on-disk label is done with 'disklabel -D'. The kernel will then
> > use a generated default label.
> 
> Writing a few sectors of garbage to /dev/rsd#d (seeking to start of file)
> won't overwrite the label.

The label sector is normally write-protected and only accessible through
special ioctls.


> Verify this by copying one disk to another:
>     dd if=/dev/rsd0d of=/dev/rsd1d bs=1024k
> and verifying the label of the destination disk isn't altered (?)

If there is no label on the disk, then you will get an artificial
'default label'. If there is a label on the disk, it will be read
and used by the first opener of the device, so disklabel would indeed
show the altered values.


> Bottom line:  I'm trying to expose the "native" (avoiding the use of the
> word "raw" to minimize the association with the "character device") disk
> interface to my code so I can put what I want

The "native" disk interface is what you use and has its limits.
Fortunately this is only relevant to a few low-level tools and
several additional interfaces were added to address the shortcomings.

To access the raw disk nowadays you would:

- 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.
- use lseek/read or pread to read sectors
- use lseek/write or pwrite to write sectors
- use ioctl(...,DIOCCACHESYNC,...) to force the disk to write cached data.
- close() the descriptor when done.

But if you do this and change how the OS sees the disk (i.e. change
partitioning or similar), you'd just create confusion.


> as I don't expect NetBSD to "use" the disk in any way).  And, trying to
> figure out what contractual guarantees I can get from the OS to stay out
> of my way in doing so.

You apparently want to bypass the OS. Don't do that.


> OK.  Again, I can look through the source to see what the actual mechanism
> is (to reproduce it in my code).

Hopefully not. The actual mechanism might not even be close to what you
can assume as 'guaranteed'.


> Do you happen to know if SATA/SAS are *inherently* hotpluggable?  Or, do
> they need *hardware* support on the motherboard/backplane to do this?

Hotplug is an optional feature. For one you want special connectors that
connect ground first and disconnect ground last. Normal SATA won't have
that but eSATA and also special backplanes have that. For two, a SATA
controller with hotplug can detect when a disk is unplugged and plugged
similar to USB and signal the driver about it. But that feature isn't
supported by the NetBSD driver yet.


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