Very Computer

Hi, I have a problem translating ssdX device names reported by iostat
(even with -n) to cXtXdX. None of the solutions/scripts I found so far
worked for me, as they usually rely on grepping /etc/path_to_inst and
looking for a matching link in /dev/rdsk. This does not work here, the
links do not exist. Could the problem be that the disks are managed by
VRTSvm? Example:

    6.1    1.7 2086.1  709.9  0.0  0.1    0.6   10.2   0   6 ssd501

Thorsten

On Mon, 04 Apr 2005 10:09:38 -0700, Michael Vilain

If I understand you correctly, one of the big difficulties that the
/dev tree is not managed by the operating system. This may result in
the appearance of 'ghost' devices - devices that are left over from
previous instantiations of the OS. Additionally, some configurations -
especially RAID ones - may have devices that are present in the /dev
tree but not current plumbed to a /devices entry.

The /devices tree is managed by the OS, so it is the system of record
for devices.

When I had to write a program to match sdxx to cxtxdxsx, I ended up
having to walk the /devices tree pulling disk devices, then walk the
/dev tree and determine which ones matched.

-david-

If by "operating system" you mean "kernel", then yes, that's true.
However, if you include devfsadmd as part of the operating system
like I do, then it's not true.

Quote:> This may result in
> the appearance of 'ghost' devices - devices that are left over from
> previous instantiations of the OS.

You can find whether those exist by doing "devfsadm -Cnsv".
And you can remove them with "devfsadm -Cnv".

Quote:> Additionally, some configurations -
> especially RAID ones - may have devices that are present in the /dev
> tree but not current plumbed to a /devices entry.

Hmm, how would that happen?  How could they be of any meaning, unless
something were creating device nodes in /dev?  And if that were happening,
isn't that supposed to be a no-no now that /devices exists?

Quote:> The /devices tree is managed by the OS, so it is the system of record
> for devices.

Yes, in the sense that /devices is always supposed to correspond
pretty directly to the kernel's view of the devices that actually
exist arranged in a hierarchy that corresponds to their relation
to each other.  But as I mentioned before, neither of them is
managed by the OS itself.

   - Logan

On Tue, 05 Apr 2005 01:27:12 GMT, Logan Shaw

Yes, I meant kernel. Sorry for the imprecise language. I'm not sure I
would include administrative programs as part of the OS per se.

Quote:

>> This may result in
>> the appearance of 'ghost' devices - devices that are left over from
>> previous instantiations of the OS.

>You can find whether those exist by doing "devfsadm -Cnsv".
>And you can remove them with "devfsadm -Cnv".

Yes, however many, many systems are not run this way. (i.e. with the
junk that accumulates over time cleaned up)

Quote:

>> Additionally, some configurations -
>> especially RAID ones - may have devices that are present in the /dev
>> tree but not current plumbed to a /devices entry.

>Hmm, how would that happen?  How could they be of any meaning, unless
>something were creating device nodes in /dev?  And if that were happening,
>isn't that supposed to be a no-no now that /devices exists?

I have seen this with Hi-Av systems where the secondary (spare,
whatever) has references to devices in /dev but, due to the current
role of the server (i.e. secondary) are not active with respect to the
devices they reference. Even in cases as simple as dual-initiated
SCSI, the secondary is typically disabled from accessing the disk
devices until its role is changed to become primary.

In simpler cases,  entries are left in /dev that point to /devices
entries that simply no longer exist due to hardware configuration
changes, changes in drivers or software, etc.

Quote:

>> The /devices tree is managed by the OS, so it is the system of record
>> for devices.

>Yes, in the sense that /devices is always supposed to correspond
>pretty directly to the kernel's view of the devices that actually
>exist arranged in a hierarchy that corresponds to their relation
>to each other.  But as I mentioned before, neither of them is
>managed by the OS itself.

I was with you until the last sentence. If by OS you mean kernel, then
the /devices tree is explicitely managed and guaranteed to be the
representation of the kernel's understanding (view) of the hierarchy
of devices under its control. So, its not a case of neither, but
rather one of them not be managed (i.e. /dev).

However, you say that your definition of OS includes the various
administrative programs shipped with the kernel. In that context, the
relationship between /dev and /devices *is* managed via the devfsadm
mechanisms you describe. So, how is the OS (under your definition) not
managing the relation?

Quote:>   - Logan

Hmm, I think I wrote that wrong.  I must've meant to say
"neither of them is managed by the kernel itself".

Quote:> If by OS you mean kernel, then
> the /devices tree is explicitely managed and guaranteed to be the
> representation of the kernel's understanding (view) of the hierarchy
> of devices under its control. So, its not a case of neither, but
> rather one of them not be managed (i.e. /dev).

Both of them are managed by devfsadmd.  From "man devfsadmd":

    DESCRIPTION
         devfsadm(1M) maintains the /dev and /devices namespaces.  It
         replaces  the  previous  suite of devfs administration tools
         including drvconfig(1M),  disks(1M),  tapes(1M),  ports(1M),
         audlinks(1M), and devlinks(1M).

         The default operation is to attempt to load every driver  in
         the  system  and  attach  to  all possible device instances.
         devfsadm then creates device special files in  /devices  and
         logical links in /dev.

         devfsadmd(1M) is the daemon  version  of  devfsadm(1M).  The
         daemon  is  started  by  the  /etc/rc* scripts during system
         startup and is responsible for handling both reconfiguration
         boot  processing  and updating /dev and /devices in response
         to dynamic reconfiguration event notifications from the ker-
         nel.

So, as far as I can tell, the only real differences in up-to-date-ness
of /dev vs /devices are:

(a) old stuff is not deleted from /dev by default,
(b) several files (/etc/path_to_inst for example) help determine
     what /dev looks like, which I think what /devices looks like
     is not a function of any files like that or at least not as
     many(?), and
(c) brain-damaged third-party programs that don't grok the Solaris
     way of doing things are MUCH less likely to go rooting around
     in /devices than they are in /dev.  :-)

In conclusion, I still don't understand all the intracacies of
/dev and /devices.  And it has been like 10 years now that I've
been using systems that have them.  :-)

   - Logan

On Tue, 05 Apr 2005 22:40:51 GMT, Logan Shaw
[snip]

Quote:>So, as far as I can tell, the only real differences in up-to-date-ness
>of /dev vs /devices are:

>(a) old stuff is not deleted from /dev by default,
>(b) several files (/etc/path_to_inst for example) help determine
>     what /dev looks like, which I think what /devices looks like
>     is not a function of any files like that or at least not as
>     many(?), and
>(c) brain-damaged third-party programs that don't grok the Solaris
>     way of doing things are MUCH less likely to go rooting around
>     in /devices than they are in /dev.  :-)

>In conclusion, I still don't understand all the intracacies of
>/dev and /devices.  And it has been like 10 years now that I've
>been using systems that have them.  :-)

>   - Logan

So, we are really almost saying the same thing. I am saying that you
cannot trust /dev for reasons a and c above. In my experience the only
reliable way to associate /devices with /dev was by walking /devices
first and then finding matches in /dev. This saves you infinite
headaches when attempting to ioctl a device from /dev that does not
link to an active entry in /devices for example.

For my part, I knew that /devices was the better selection as the
system of record for device entries, but did not fully understand the
mechanics behind it (I thank you for your explaination).

This whole thing was made painfully obvious to me when a configuration
reporting program I was supporting was finding all sorts of 'phantom'
disks and experiencing a great number of ioctl errors. The original
algorithm walked /dev and then associated /devices to it, the fixed
algorithm did the reverse.

SIDEBAR: nftw is your friend in these tree-walk cases except on
pre-Solaris 9 systems where it will not stop even when it finds the
stop condition.

FYI: one of the systems that was experiencing this problem had over
3,500 disk devices attached to it. You can bet that some considerable
time was spent making the /devices to /dev association logic as
efficient as possible.

-david-

No luck. No ssd device names in any output, no matter how verbose.

Quote:> I've also used /var/adm/messages shortly after
> boot, but that file can fill up with messages and is unreliable for
> systems that have been up a long time.

I restored a messages file from shortly after the last boot. It did show ssd
names, but they resolved to the same names as in path_to_inst :-/

Thanks so far,
Thorsten
--
This version includes the highest-accuracy voodoo OSBF classifier. Most of the
new OSBF upgrades were rolled back into OSB, including the microgroom
algorithm and CF factor, so Monkeyplexer can use these in N-way
classifications.

Quote:

> So, we are really almost saying the same thing. I am saying that you
> cannot trust /dev for reasons a and c above. In my experience the only
> reliable way to associate /devices with /dev was by walking /devices
> first and then finding matches in /dev. This saves you infinite
> headaches when attempting to ioctl a device from /dev that does not
> link to an active entry in /devices for example.

How do you match /devices entries to /dev entries? (Not at a Solaris server
right now)

Thorsten
--
This version includes the highest-accuracy voodoo OSBF classifier. Most of the
new OSBF upgrades were rolled back into OSB, including the microgroom
algorithm and CF factor, so Monkeyplexer can use these in N-way
classifications.

Non-programmatically, I would do the following:
1. ls -l the devices entry making note of the major and minor numbers
2. in /dev/dsk (or rdsk) do an 'ls -lL | grep major' to find all the
devices with the same major number.
3. select the cxtxdxsx that matches.

Example:
in /devices the entry is:

So we have major 28, minor zero.
In /dev/dsk, we find:
# ls -lL | grep 28
brw-r-----   1 root     sys       28, 16 Apr  4 20:42 c0t1d0p0
brw-r-----   1 root     sys       28, 17 Apr  4 20:42 c0t1d0p1
brw-r-----   1 root     sys       28, 18 Apr  4 20:42 c0t1d0p2
brw-r-----   1 root     sys       28, 19 Apr  4 20:42 c0t1d0p3
brw-r-----   1 root     sys       28, 20 Apr  4 20:42 c0t1d0p4
brw-r-----   1 root     sys       28,  0 Apr  4 20:42 c0t1d0s0
brw-r-----   1 root     sys       28,  1 Apr  4 20:42 c0t1d0s1
brw-r-----   1 root     sys       28, 10 Apr  4 20:42 c0t1d0s10
brw-r-----   1 root     sys       28, 11 Apr  4 20:42 c0t1d0s11
brw-r-----   1 root     sys       28, 12 Apr  4 20:42 c0t1d0s12
brw-r-----   1 root     sys       28, 13 Apr  4 20:42 c0t1d0s13
brw-r-----   1 root     sys       28, 14 Apr  4 20:42 c0t1d0s14
brw-r-----   1 root     sys       28, 15 Apr  4 20:42 c0t1d0s15
brw-r-----   1 root     sys       28,  2 Apr  4 20:42 c0t1d0s2
brw-r-----   1 root     sys       28,  3 Apr  4 20:42 c0t1d0s3
brw-r-----   1 root     sys       28,  4 Apr  4 20:42 c0t1d0s4
brw-r-----   1 root     sys       28,  5 Apr  4 20:42 c0t1d0s5
brw-r-----   1 root     sys       28,  6 Apr  4 20:42 c0t1d0s6
brw-r-----   1 root     sys       28,  7 Apr  4 20:42 c0t1d0s7
brw-r-----   1 root     sys       28,  8 Apr  4 20:42 c0t1d0s8
brw-r-----   1 root     sys       28,  9 Apr  4 20:42 c0t1d0s9

So we can find that major 28, minor 0 maps to c0t1d0s0.

-david-

Interesting.  Is there any advantage of this over just doing a
readlink of everything in /dev and using that to match things up?
It seems like the obvious thing to do, but since you have delved
into this more than many have, maybe there's a reason.

(I suppose one reason is that {character/block,major,minor} makes
a nice unique ID that is easy to index on, whereas pathnames are
hierarchical and complicated.  Especially helpful in a C program,
maybe...)

   - Logan

On Thu, 07 Apr 2005 00:40:36 GMT, Logan Shaw

Well... yes... I was trying to give a method that was
*non-programmatic*. (i.e. just using available system commands) The
readlink function is a programming api which would mean coding. My
method (albeit clunky) does not require any programming and yields
results fairly easily.

Turning back to the original problem for a second, the author wanted a
way to quickly relate ssdx devices to cxtxdxsx naming. I assumed that
the request was for a method that was quick and required a minimum
amount of fuss.

A programmatic approach would generally be more complicated involving
stat and ioctl (assuming you wanted to restrict your search to disk
devices a priori).

Quote:>(I suppose one reason is that {character/block,major,minor} makes
>a nice unique ID that is easy to index on, whereas pathnames are
>hierarchical and complicated.  Especially helpful in a C program,
>maybe...)

>   - Logan

You are correct that indexing is a nice thing to have when solving
this problem generically. Hash indexing is, naturally, even nicer ;-)

-david-

If your system is S8, then install patch 109277-04. It was a bug. Now is
resolved
Regards
Algha

Installed the path, but the problem remains :-/

Thorsten