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

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

On 9/24/2018 4:14 AM, David Brownlee wrote:
> On Mon, 24 Sep 2018 at 11:08, Don NetBSD <netbsd-embedded%gmx.com@localhost> wrote:
> > On 9/18/2018 3:54 AM, David Brownlee wrote:
> > > Just some musing about handling drive mappings:
> > >
> > > For sd devices you could use "scsictl sdX identify" to map back from
> > > sdX to (scsibus, target, lun) numbers and then onto each drive's
> > > physical location.
> >
> > OK.  That would help me initially identify the "slots" in order to
> > hard-wire them in the kernel.  I.e., stuff every slot, boot, then
> > "identify" each disk (having made the contents of each disk unique
> > enough to map to the probed devices).
> >
> > Presumably, once each slot is wired down, then it need not be
> > populated at boot -- yet the device will still exist for it when it
> > later "appears".
>
> Yes, though if you can identify the slots for hardwiring into the
> kernel you could also run the same process at runtime as run a GENERIC
> kernel.
>
> I have no idea whether this would actually map to your real
> requirements, but a possible workflow could be:
>
> Bringing up new appliance ("slot mapping")
> - Assuming you have "ID" devices digitally and physically labelled 1..n.
> - User is directed to insert as many ID devices as they have slots
> switch on machine
> - Appliance boots, detects it has devices attached, checks to see they
> are ID devices, updates slots and records its slot mappings

I would just use N different (make/model) drives for that purpose and
examine dmesg on boot:  "OK, the 500G Seacrate is located in the
top left slot and that appears to have been probed as sd0.  The 320G WD
is in the slot to its right and that seems to have been probed as sd4.
etc."  As this is only done once, I can just grab any old drives and
stuff them into the machine, knowing their contents won't be altered
(unless I screw up).  Then, put them back <wherever> once I've got
the slots marked.

I am expecting this to bear some logical relationship to how the
manufacturer designed the "drive cage" (the one server that I've
examined so far has them laid out in the order a casual observer
would expect -- no surprises, there).

I don't expect (nor want!) "them" to be able to bring up new boxes
unsupervised.  There are too many little details that could have
consequences.  E.g., any performance metrics reported for a drive
in appliance A might differ from (that same drive!) in appliance B.

> Normal use
> - When a new sdX or wdX device is detected system determines its slot
> mapping and uses it when talking to user
> - If it can't determine slot mapping, it suggests a new slot mapping
> pass (something strange has happened)
>
> Optional extra credit ("Where is what slot")
> - User is instructed to apply sticky number labels next to ID devices
> when bring up appliance

*I* would be that "user".  I imagine eventually having a "live (remote)
display" that  reports/summarizes the activities and status of each
drive slot.  Presently, that takes the form of a text display that
summarizes a single appliance on a single screen (curses).  That
could evolve into something graphical.

> Optional extra credit ("Where is what slot and sticky labels fall off")
> - User directed to take photo of appliance with ID devices to record
> where the slots were & upload to web server on applicance
> - If user is confused on slot mapping web server on appliance can show
> mapping picture
>
> Optional extra credit ("Users mess with hardware/swap disks to other machines")
> - At boot time system takes a copy of dmesg and notes the available
> atabus/scsibus and device names
> - If this ever changes it forces a new slot mapping pass

<grin>  I do product design/development for a living, not "test fixture
design".  So, I'm not too keen on embelishing this more than necessary
(and delaying the NEXT product's delivery!)