Wandering Thoughts archives

Oracle shows its appreciation for long-term Sun customers again

I suppose that this is not exactly news, but I noticed recently that as part of its 'transition' of sun.com (aka getting rid of sun.com), Oracle has of course gotten rid of docs.sun.com as well. Just as they've done with other sun.com properties, there are no specific redirections for old docs.sun.com URLs; all URLs now wind up on a generic Oracle documentation website.

So let me summarize that: Oracle broke all old links to Sun documentation.

All of those links to Sun docs that are in our documentation and notes, and perhaps yours as well? Dead. All of those links on people's web pages that say some variant of 'and here's the official documentation for more information'? Dead. All of those URLs for manuals that you were going to get around to reading sometime? Well, you get the theme here. This is an especially annoying situation for docs.sun.com because the documentation URLs that Sun used were so meaningless by themselves. If all you have is an old URL, you probably now have essentially no chance of figuring out what manual it went to so that you can look it up on the new Oracle documentation site.

I'm aware that this is nothing new for old Sun URLs, and that some of the things that have happened as a result are much more annoying and troublesome. It's just that for some reason, this particular set of URLs going away really gets to me (partly, I admit, because I have some links to Sun documentation in WanderingThoughts entries, links that are now dead).

(For a somewhat more important example, ZFS error status URLs now redirect to something that wants you to log in to Oracle's support system. They may or may not work after you do that.)

How we handle iSCSI device names in Solaris

One of the quite important things we've done in our SAN environment is that our local software hides the real Solaris device names in favour of local labels for iSCSI devices. Hiding the real device names is not something that's normally recommended, but I feel that iSCSI is a special case, especially in a Solaris environment with MPxIO enabled.

First off, let me give you a concrete example that may illustrate why we hide device names. Here is the normal Solaris device name for a disk and the iSCSI name we use:

c2t49455400000000006F7377616C6430316935000000000000d0

oswald:disk01/0

(I think you can tell which is which.)

Yes, that's a huge device name. This is the kind of device names that you get with MPxIO, because MPxIO basically encodes a disk's identifying information in the official device name (as you might guess from the embedded hex). This is all well and good, but it means that if you use MPxIO you can easily have a whole bunch of very long names that differ in only small and basically opaque ways. Even with cut and paste it would be terribly easy to make a mistake, and I don't want to think about copying these names by hand.

The bigger problem is that Solaris device names for iSCSI devices have very low information content; with or without MPxIO, they're essentially opaque magic identifiers. To do anything much with them you need to reverse them back to determine what iSCSI target device they correspond to, because that's the only way to understand what you're doing or what's going on (or gone wrong). By contrast, our transformation of the names has very high information content; it immediately identifies the iSCSI backend, the specific physical disk on the backend, and the logical chunk from the disk.

In short, our hiding the device names transforms a mere identifier for the disk to the identity of the disk.

(This is not (and cannot be) a generic, site independent transformation. Our naming and remapping process only makes sense in our environment; in a different environment with a different iSCSI topology you would want to emphasize different things about the identity of the disk.)

There are drawbacks to doing this hiding; for a start, we need to do some extra work in scripts pretty much every time we deal with devices. Since Solaris doesn't directly export MPxIO mapping information for iSCSI devices in a machine readable format, this means we get to run iscsiadm and parse its output (which has the usual hazards). Still, I think that it's worth it; the visibility it gives us for what we're doing and what's going on is very important in practice.

(Most of our locally written tools degrade gracefully if they can't get this mapping information, displaying and accepting 'raw' Solaris device names. And of course we can always work directly with the ZFS commands, which of course only deal with Solaris device names.)