On Tue, 25 Sep 2018 at 06:51, Don NetBSD <netbsd-embed...@gmx.com> wrote: > > On 9/24/2018 4:14 AM, David Brownlee wrote: > > On Mon, 24 Sep 2018 at 11:08, Don NetBSD <netbsd-embed...@gmx.com> 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