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

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

On 9/16/2018 12:21 AM, Michael van Elst wrote:
> netbsd-embedded%gmx.com@localhost (Don NetBSD) writes:
>
> > But can't I walk back up the device tree and find the number of leaves
> > on a particular (physical) controller?
>
> You could find out from the config file how many disks you have wired.
> Still unrelated to real hardware.

That gives me a number for the "MAX_DRIVES_SUPPORTED" manifest constant
in my code (I have to put SOME limit on how many devices can be handled).
Said a more practical way, I can make sure I build a kernel that handles
at least as many devices as my code will handle (silly for my code to
handle more than the kernel supports)

> > > 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)
>
> If the driver presents the disks as sd(4) devices, you get some
> virtual unit that just happens to be usuable to access the
> physical one.
>
> For example, the mfi(4) driver would present the disks to you as
> sd(4). However, such an sd device would emulate the basic read/write
> commands. It also passes through other commands, but your SATA devices
> would have problems to understand SCSI commands.

Ah!  So, the sd(4) driver won't pass "non-scsi" commands and
the sd(4) devices might not accept scsi commands.  (damned if you
do, damned if you don't)?

> > But, I would have to rely on empirical observation to know which device
> > is which?
>
> Yes. Fortunately we still enumerate devices serially, so the numbers don't
> change.

I'd have to make sure I numbered the targets on each scsibus as well.
And, size each to handle the largest shelf that might be attached to it.
So, if I have a 15 drive shelf today, I'd number those slots 1-15.
The second shelf, 16-32.  Etc.

If, thereafter, the first shelf was replaced with an 8 drive shelf, then
devices 9-15 would just disappear -- 16 would continue to be the first
device on the second shelf.

> The kernel configuration of course will be specific to your machine then.
> If you replace hardware you might need a new configuration.

Yes, that's what I'm trying to guard against.  I can almost guarantee
that someone will get the "bright idea" that they can hack together a
second appliance -- using DIFFERENT hardware (a computer is a computer,
right?) and just cloning the system disk.  Then, complain when it
doesn't work as expected.

The only ways I can think of to hard-wire the software (and kernel config)
to the machine is to examine the MAC(s) in the machine and compare against
hard-coded values.  Or, PXE serve *a* kernel based on the MAC of the
client requesting it.  (this latter lets me painlessly address future
needs assuming the MACs are immutable)

> > > > 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.
>
> Simple passive shelfs aren't even visible. It's like the disks in that
> shelf are dead if the shelf is removed. If you wire down scsibus to
> specific controllers/ports and sd devices to specific scsibusses and
> target/lun ids, nothing will change when a shelf is removed.

The key, there, is to wire down the scsibus and ensure the SAS cables
aren't swapped/misplugged.  I'm obviously trying to avoid all the
potential screwups that can happen after I release the fixture to
Manufacturing.

OK, I guess I'll drag out a few shelfs and start poking at them
to see what they reveal.  Or, maybe wait until I have access to
the "real" kit so I don't make assumptions based on MY hardware
that prove to be incompatible with the boss's stuff.

Thanks!