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

[David Brownlee <abs%absd.org@localhost>]

On Tue, 25 Sep 2018 at 06:51, Don NetBSD <netbsd-embedded%gmx.com@localhost> wrote:
>
> 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:
> >
> > 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.

Mmm finding and maintaining N different models of drives might be a
pain. If you have how swap bays you could always script up something
like
"put disk in slot 1 and hit return or Q to quit"
"..."
"OK identified, move disk from slot 1 to slot 2 and hit return or Q to quit"

Also provides an inline test of the hot swap facility :)

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

Reasonable, but its always nice to design what would be the full
robust system, and then decide what corners to cut :-p, plus from past
experience you invariably end up at some point needing to build a box
at the same time as your attention is split fielding something else
urgent.

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

Usually a big fan of html in this case - can start by spitting out a
static html page with a table and 30 second meta refresh, and extend
to some simple javascript which refreshes within page...

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

We all have to start somewhere :-p

> So, I'm not too keen on embelishing this more than necessary
> (and delaying the NEXT product's delivery!)

It sounds like you have all the right ideas - we're fascinated to hear
how it goes! :)

David