One of the more interesting features of Solaris is the way in which is handles its device naming. In order to make things simple and maintain some sense of uniformity across the wide array of hardware it supports, your average Sun sparc box refers to its disk devices as

/dev/<r>dsk/cXtYdZsN

Where X is controller, Y is target, or LUN Z is the device number and N is the slice (0-7) on that device.

Dig a little deeper however and you'll see that what may be /dev/dsk/c0t0d0s0 is actually a symbolic link to something like:

/devices/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@0,0:a

This represents the actual physical connection of the device to the system. Working backwards, the device is the 'a' slice (:a) on a SCSI disk (sd) with target 0 (@0) LUN 0 (,0). This is connected to an esp SCSI host adapter (esp@f,800000 - the espdma@f,4000 is DMA information) plugged into SBUS slot 'f' (sbus@f) which is itself connected to the system bus by the I/O memory management unit (iommu) at address e0000000.

Consider trying to manually mount a device using that pathname and you'll quickly understand why the alias exists!

In order to create these symbolic names the Solaris operating system needs to probe the system and build up a list of things like controllers, disks, ethernet interfaces and other devices connected to the system. It tries to number them logically - so the first detected controller is given the name 'c0' or 'controller 0', the second controller is given 'c1' or 'controller 1' and so on.

Now here's the problem. If, after the system has been set up, you add another controller, or attach devices to an existing controller which is attached to the system logically before an existing controller (eg: has an address lower than what is currently referred to as controller 0) the system must give it a symbolic name which is not already in use. Let's say it chooses 'controller 1'. So we now have a situation where c0 and c1 are in effect backwards in terms of the logical manner in which they are connected to the system. This does not matter because it is transparent to the running operating system. You can call the second controller 'c7' and it will not matter a bit, because the symbolic link still points to the correct device.

BUT!

Should you want to boot from CDROM or otherwise upgrade the operating system, you have a situation where the devices and entries in the /dev directory get rebuilt. Guess what? c0 and c1 get swapped! What you think is your boot disk on c0t0d0s0 is now actually c1t0d0s0. This can cause havoc for the unwary.

You have been warned!

For those of you with sunsolve access, this problem is outlined in infodoc 2224.