Re: Sizing hardware drive capabilities (in the absence of probed devices)

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

On 9/15/2018 11:27 PM, Michael van Elst wrote:
> netbsd-embedded%gmx.com@localhost (Don NetBSD) writes:
>
> > How can I determine the number of /potential/ disk devices (sd(4))
> > that a system MIGHT support -- *if* the drives had been installed
> > prior to boot?
>
> That would be difficult. sd(4) is used for several different kinds
> of disks, including virtual ones and SCSI is a bus. You MIGHT
> install hundreds of sd devices but that's unrelated to e.g. how
> many drive slots the machine has.

But can't I walk back up the device tree and find the number of leaves
on a particular (physical) controller?  Note that I control the
kernel configuration so devices can't exist where i don't expect
them...  (e.g., remove the USB devices from the configuration
file and the possibility of a mass device being inserted goes away).

> > E.g., if I have a 15 slot backplane but only have
> > a drive installed in slot 13, then *that* appears as sd0 and there
> > is no mention of the potential for the other 14 drives.
>
> A backplane might support a ses(4) enclosure device that could
> be queried.

The backplane on the machine I'm currently using has no ses device
probed.  Yet, the kernel seems to know that there are 4 drives installed
(*IF* they are present when the machine is booted!)

> A driver for a multiport controller usually knows how many ports
> are available. But that's not exposed, and in case of a bus
> topology, you still wouldn't know what is possible.
>
> > Presumably, I can wire down each sd(4) device to correspond to a
> > particular "slot" (SATA port) in the machine when I build a kernel
> > with that in mind.
>
> SATA would be wd(4), not sd(4).

SATA on a SAS controller appear as sd(4) devices on scsibus's.
Not sure I have the option to attach them to atabus, instead
(nor why I would want to do that)

> > [This allows software to KNOW that sd0 is "the drive in the top
> > left slot" even if there is no drive present there when the machine
> > boots]
>
> You could create a custom kernel that wires drive units to specific
> locations. You'd also may need to wire the 'scsibus' instances.

But, I would have to rely on empirical observation to know which device
is which?

> For SATA that would wd devices and atabus instances.
>
> USB might be an issue. You may need to remove the umass driver so
> that no SCSI or ATA instances can attach.

Exactly.  The issue then becomes one of ensuring a particular slot/bay
in a particular shelf maps to a particular /dev/sd*.  I'd have to
label the slots, label the shelfs, label the SAS cables (and which
connectors they attach to).  But, so long as no one swaps cables,
things should stay as intended.

If a shelf is not powered on at boot, then I'd have to wire down the
associated controller/scsibus and make provisions to reprobe it when
it comes online.

> > How can I configure a kernel to support a very large number of
> > (wired down) drives even if the hardware to support those drives
> > isn't present (I'm thinking about the case of having a couple
> > of disk shelfs which may/may not be present at any given time)?
>
> Disk shelfs are irrelevant, controllers, channels, target and
> lun ids are. The scsi and ata manpages give some examples about
> possible kernel configurations to wire down disks.

The shelfs are relevant because they can be "removed"  in much
the same way that a drive can be removed.  Not planning for that
possibility means an operator may be receiving directions regarding
"remove drive 5" when, in fact, the shelf in which "5" is installed
happens to have labeled it as "20".

Man pages indicate syntax for wiring down but give no guidance as
to how (other than empirical) to figure out which is which.  E.g.,
for PATA, you knew MASTER vs. SLAVE.  Does driver probe the controller
in the order the motherboard manufacturer has defined "SATA connections"?
(and, how might that relate to a backplane where there is nothing
besides OCD to force the slots to appear in a particular order)