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

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

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

David

On Sun, 16 Sep 2018 at 20:02, Don NetBSD <netbsd-embedded%gmx.com@localhost> wrote:
>
> On 9/16/2018 2:27 AM, Michael van Elst wrote:
> > netbsd-embedded%gmx.com@localhost (Don NetBSD) writes:
> >
> >> Ah!  So, the sd(4) driver won't pass "non-scsi" commands and
> >> the sd(4) devices might not accept scsi commands.  (damned if you
> >> do, damned if you don't)?
> >
> > The sd driver just passes some byte sequence, some are intercepted by
> > mfi, some aren't. The mfi firmware might do more before it actually
> > reaches the disk.
>
> The 2950 uses an mpt(4) -- though I suspect your points apply equally.
>
> >> I'd have to make sure I numbered the targets on each scsibus as well.
> >
> > Yes, you need to wire scsibus (if there could be more than one) and
> > you need to wire sd.
>
> So, my kernel config should contain N+1 sd entries (the N+1th for a
> wildcarded "sd?") each with specific unit numbers.  Ditto scsibus(4)'s
> as well as the controller (mpt) to which they attach.  In this way, I
> should be able to rely on the /dev mappings to specific hardware (even
> in the absence of said hardware or portions thereof).
>
> >> Yes, that's what I'm trying to guard against.  I can almost guarantee
> >> that someone will get the "bright idea" that they can hack together a
> >> second appliance -- using DIFFERENT hardware (a computer is a computer,
> >> right?) and just cloning the system disk.  Then, complain when it
> >> doesn't work as expected.
> >
> > You need to wire down scsibus to a specific controller. I.e. adding
> > another controller or replacing it with a different model makes your
> > kernel config void.
>
> That's acceptable -- it's an *appliance*, not a "general purpose computer".
> I just need to ensure that the software either knows that the configuration
> has been changed (and can complain about it) *or* lock the system (hardware
> and software) so it *can't* be changed.
>
> (sigh)  This would be *so* much easier if I just pulled product off the Line
> and tweeked the firmware!  "Want another?  Go get one (and *I* know it will
> be identical to the last!)"