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 d
On Tue, 25 Sep 2018 at 06:51, Don NetBSD wrote:
>
> On 9/24/2018 4:14 AM, David Brownlee wrote:
> > On Mon, 24 Sep 2018 at 11:08, Don NetBSD wrote:
> >
> > I have no idea whether this would actually map to your real
> > requirements, but a possible workflow could be:
> >
> > Bringing up new appli
On 9/24/2018 4:14 AM, David Brownlee wrote:
On Mon, 24 Sep 2018 at 11:08, Don NetBSD wrote:
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 a
On Mon, 24 Sep 2018 at 11:08, Don NetBSD wrote:
>
> 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
> >
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 "s
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 r
On 9/16/2018 2:27 AM, Michael van Elst wrote:
netbsd-embed...@gmx.com (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, som
netbsd-embed...@gmx.com (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
On 9/16/2018 12:21 AM, Michael van Elst wrote:
netbsd-embed...@gmx.com (Don NetBSD) writes:
But can't I walk back up the device tree and find the number of leaves
on a particular (physical) controller?
You could find out from the config file how many disks you have wired.
Still unrelated to r
netbsd-embed...@gmx.com (Don NetBSD) writes:
>But can't I walk back up the device tree and find the number of leaves
>on a particular (physical) controller?
You could find out from the config file how many disks you have wired.
Still unrelated to real hardware.
>The backplane on the machine I'm
On 9/15/2018 11:27 PM, Michael van Elst wrote:
netbsd-embed...@gmx.com (Don NetBSD) writes:
How can I determine the number of /potential/ disk devices (sd(4))
that a system MIGHT support -- *if* the drives had been installed
prior to boot?
That would be difficult. sd(4) is used for several di
netbsd-embed...@gmx.com (Don NetBSD) writes:
>How can I determine the number of /potential/ disk devices (sd(4))
>that a system MIGHT support -- *if* the drives had been installed
>prior to boot?
That would be difficult. sd(4) is used for several different kinds
of disks, including virtual ones a
How can I determine the number of /potential/ disk devices (sd(4))
that a system MIGHT support -- *if* the drives had been installed
prior to boot? E.g., if I have a 15 slot backplane but only have
a drive installed in slot 13, then *that* appears as sd0 and there
is no mention of the potential f
13 matches
Mail list logo
