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

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

On 9/25/2018 3:19 AM, David Brownlee wrote:

[attrs elided]

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

The point is NOT to be required to have "special disks" (e.g., your disks
with ID's written on the media).  Pick up N disks that differ in some way
from each other (size, manufacturer) and stuff them into slots.  Watch
the dmesg output as those are probed.  Return the disks to their original
homes.

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

The "right solution" is to use our existing product as the fixture!
- we already own the hardware design (and know how to troubleshoot it)
- can get replacement parts any time (what if the server shits the bed?)
- can build as many as we like (no hunting for identical/compatible servers)
- own all the sources (and know how they work!)
- don't have to worry about hot swap (just power the device down, remove
  the drive, insert another, power up -- near instantaneous boot)
- don't have to go "exploring" all of these issues

*This* approach is the result of someone with a superficial knowledge of
the issues spouting off to Management ears that were foolishly receptive
to the -- ahem -- "short cut".  I'll be able to prove that when I'm done.

My interest, now, lies in how I could exploit this approach for some
other organizations with which I'm affiliated (that DON'T have an existing
product line that they could repurpose for the task).

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

With *no* experience in HTML, I've actually become VERY interested in
using it to make "platform independent" interfaces.  E.g., interfaces
that I could serve over a phone (via WiFi) without having to write
applications that run *in* the phone.

[Looking at designing a remote display for a pallet scale, presently, so
a forklift operator can just look at his phone to see how much the
pallet of goods weighs WITHOUT having to exit the vehicle and walk up
to the (small) display located indoors.]

> > <grin>  I do product design/development for a living, not "test fixture
> > design".
>
> We all have to start somewhere :-p

I did my stint with production test several decades ago.  Considerably
more labor intensive, back then.  Hence my fear of letting this turn
into a "project" that THEY have to maintain.

> > 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! :)

Presently, I'm more interested in what I can do for OTHER folks using
a similar approach (COTS hardware vs. something "owned" but proprietary).
But, let some one else pay me to learn what I want to learn...  <grin>