Re: disk geometry (i386/amd64)

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

On 9/8/2018 11:55 PM, Michael van Elst wrote:
> NetBSD-embedded%gmx.com@localhost ("Don NetBSD") writes:
>
> > My understanding is that the 'd' partition is intended to reference the
> > entire medium.  But, a simple test (disklabel -e) indicates that I can
> > create an arbitrary (start,size) for that partition.  So, I could
> > potentially encounter a foreign disk that happens to *look* like it has a
> > 'd' partition that doesn't map to the actual entire physical disk.
>
> The 'd' partition is the raw partition (on x86, other architectures use
> 'c'). Accesses to the raw partition ignore the disklabel values.

Yet manually editing any of the parameters in the label via disklabel(8)
(d partition size/offset, total sectors, # cylinders, sectors/track, etc.)
*persists* across disklabel(8) invocations.  Apparently, these are only stored
in the kernel and not rewritten to the physical medium (?) -- i.e., they
don't persist across a reboot.

[I've verified both of these claims]

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?

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?  (In my example, disklabel(8) is getting
the modified-to-be-incorrect values from *somewhere*...)

> N.B. 'sysctl kern.rawpartition' shows what the raw partition is
> (0='a',1='b',2='c',..).
>
> > How can I get the actual geometry and ensure any bogus label contents are
> > obliterated (i.e., overwriting the entire medium regardless of the
> > "protected" MBR/label space)?
>
> The disklabel stores the physical geometry, but that's mostly what has been
> stored in the on-disk disklabel. The driver also knows the geometry from the
> drive itself. You can query this data using 'drvctl -p'.

I'm looking for programmatic ways of doing so (omit most/all of the filesystem
contents).

Obviously, if drvctl(8) can report the "real" values, then they must be
preserved somewhere besides the in-kernel disklabel.  (?)  And, somewhere
that can't be mucked with by altering the contents of the disklabel portion
of the medium!

[I'll grep the source to see...]

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

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, where I want it (as long
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.

[The alternative is to resort to bare metal programming and elide all
of the muck that is associated with a "PC"]

> > Related but different question:  is there any support for hot-plugging
> > (unplugging) drives (other than USB) on NetBSD?  I know you can kludge
> > this with external SCSI drives if the i/f is quiescent and you then rescan
> > the appropriate scsibus.  But, how does SATA/SAS cope?
>
> About the same. There is an autoconfig feature in the drivers to 'rescan'
> which can be triggered with 'drvctl -r'. ATA needs an additional parameter,
> i.e. 'drvctl -r -a ata_hl atabus1' will try to attach drives on 'atabus1'.
> For hotplug you would first detach the old drive with 'drvctl -d' and then
> rescan.

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

Do you happen to know if SATA/SAS are *inherently* hotpluggable?  Or, do
they need *hardware* support on the motherboard/backplane to do this?
I.e., is "support for hotplugging" entirely a software ("BIOS") issue?

Thanks for your help!