NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Sizing hardware drive capabilities (in the absence of probed devices)
- Subject: Re: Sizing hardware drive capabilities (in the absence of probed devices)
- From: Don NetBSD <netbsd-embedded%gmx.com@localhost>
- Date: Mon, 24 Sep 2018 03:07:56 -0700
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".
The drives would need to be labelled via GPS and the software set to
mount via named slices for referencing data on each drive.
It would even mean someone could pull a set of drives from one machine
to another and as long as they get the boot drive right the order of
the others is irrelevant.
There's no "other (NetBSD) machine", here. The drives "go their separate ways"
once I've finished with them. Think of it as a "PROM programmer" that can
handle multiple devices at the same time. The disks are the equivalent of
the PROMs. "Program" them and then remove them from the fixture and use
them <wherever>
For indicating which drive to pull one thought would be to quiesce all
other drives then pulse activity on the drive to pull for 5 seconds.
Quiescing the other drives would be unfortunate. The goal is to be able
to have a more-or-less continuous process whereby drives are inserted,
processed and extracted regardless of the state/activity of the other
drives in the appliance.
An "operator" will power up the appliance and insert the drives that
need to be "processed" (they will likely NOT be the same nor require the
same processing). He will "Start" a particular slot and then move on
to some other activity. When informed that a slot is finished (successfully),
he will "Eject" that disk, slap a label onto it that has been printed
for it (by the same appliance), place the disk in a "completed" pile and
insert another disk in the now vacant slot.
Lather, rinse, repeat.
When the last disk is finished, the appliance will power itself down
(having logged the results of each disk in the event the power-down
occurs after the close of business). The process will repeat on the
next day/shift.
Home |
Main Index |
Thread Index |
Old Index