Device Naming

  1. Device Naming
    1. Introduction
    2. Linux device naming
    3. Windows device naming
    4. FreeBSD device naming
    5. Solaris device naming
    6. Examples

Introduction

Device naming of storage devices varies from between operating systems and sometimes between different releases of the same operating system. This page attempts to cover the device naming conventions for various storage related packages written by this author. Some of these packages are Linux specific, while others were originally written for Linux then ported to various other operating systems.

The overall device naming philosophy is to follow the device naming conventions of each operating system, rather than attempt to follow a "one naming convention fits all" approach. There is a section below for each supported operating system. Since most of the examples on the utility web pages and the man pages are for Linux, some familiarity with Linux storage device naming conventions may help users of other ports.

Linux device naming

Normal disk block devices have names like /dev/sda, /dev/sdb, /dev/sdc, etc. SCSI disks in Linux have always had names like that but in recent Linux kernels (e.g. lk 2.6 series) it is becoming more common for almost all disks to be named like that. Partitions within a disk are specified by a number appended to the device name, starting at 1 (e.g. /dev/sda1 ).

Tape drives are named /dev/st<num> or /dev/nst<num> where <num> starts at zero. Additionally one letter from this list: "lma" may be appended to the name. CD, DVD and BD readers (and writers) are named /dev/sr<num> where <num> start at zero. There are less used SCSI device type names, the dmesg and the lsscsi commands may help to find if any are attached to
a running system.

There is also a SCSI device driver which offers alternate generic access to SCSI devices. It uses names of the form /dev/sg<num> where <num> starts at zero. The lsscsi -g command may be useful in finding these and which generic name corresponds to a device type name (e.g. /dev/sg2 may correspond to /dev/sda). In the lk 2.6 series a block SCSI generic driver was introduced and its names are of the form /dev/bsg/<h:c:t:l> where h, c, t and l are numbers. Again see the lsscsi command to find the correspondence between that SCSI tuple (i.e. <h:c:t:l>) and alternate device names.

Prior to the Linux kernel 2.6 series these utilities could only use generic device names (e.g. /dev/sg1 ). In almost all cases in the Linux kernel 2.6 series, any device name can be used by these utilities.

Windows device naming

Storage and related devices can have several device names in Windows. Probably the most common in the volume name (e.g. D: ). There are also a "class" device names such as PhysicalDrive<n>, CDROM<n> and TAPE<n>. <n> is an integer starting at 0 allocated in ascending order as devices are discovered (and sometimes rediscovered).

Some storage devices have a SCSI lower level device name which starts with a SCSI (pseudo) adapter name of the form SCSI<n>: . To this is added sub-addressing in the form of a "bus" number, a "target" identifier and a "lun" (logical unit number). The "bus" number is also known as a "PathId". These are assembled to form a device name of the form: SCSI<n>:<bus>,<target>,<lun> . The trailing ",<lun>" may be omitted in which case a lun of zero is assumed. This lower level device name cannot often be used directly since Windows blocks attempts to use it if a class driver has "claimed" the device. There are SCSI device types (e.g. Automation/Drive interface type) for which there is no class driver. At least two transports ("bus types" in Windows jargon): USB and IEEE 1394 do not have a "scsi" device names of this form.

In keeping with DOS file system conventions, the various device names can be given in upper, lower or mixed case. Since PhysicalDrive<n> is tedious to write, a shortened form of PD<n> is permitted by all utilities.

A single device (e.g. a disk) can have many device names. For example: PD0 can also be C: , D: and SCSI0:0,1,0 . The two volume names reflect that the disk has two partitions on it. Disk partitions that are not recognised by Windows are not usually given a volume name. However Vista does show a volume name for a disk which has no partitions recognised by it and when selected invites the user to format it (which may be rather unfriendly to other OSes).

These utilities assume a given device name is in the Win32 device namespace. To make that explicit "\\.\" can be prepended to the device names mentioned in this section. Beware that backslash is an escape character in Unix like shells and the C programming language. In a shell like Msys (from MinGW) each backslash may need to be typed twice.

The sg_scan utility in the sg3_utils package lists out Windows device names in forms that are suitable for other utilities to use. Note that Windows operating systems prior to Windows 2000 are not supported.

FreeBSD device naming

SCSI disks have block names of the form /dev/da<num> where <num> is an integer starting at zero. The "da" is replaced by "sa" for SCSI tape drives and "cd" for SCSI CD/DVD/BD drives. Each SCSI device has a corresponding pass-through device name of the form /dev/pass<num> where <num> is an integer starting at zero. The camcontrol devlist command may be useful for finding out which SCSI device names are available and the correspondence between between class and pass-through names.

Solaris device naming

SCSI device names below the /dev directory have a form like: c5t4d3s2 where the number following "c" is the controller (HBA) number, the number following "t" is the target number (from the SCSI parallel interface days) and the number following "d" is the LUN. Following the "s" is the slice number which is related to a partition and by convention "s2" is the whole disk.

OpenSolaris also has a c5t4d3p2 form where the number following the "p" is the partition number apart from "p0" which is the whole disk. So a whole disk may be referred to as either c5t4d3, c5t4d3s2 or c5t4d3p0 . See this page for more information.

And these device names are duplicated in the /dev/dsk and /dev/rdsk directories. The former is the block device name and the latter is for "raw" (or char device) access which is what sg3_utils needs. So in OpenSolaris something of the form 'sg_inq /dev/rdsk/c5t4d3p0' should work. If it doesn't work then add a '-vvv' option for more debug information. Trying this form 'sg_inq /dev/dsk/c5t4d3p0' (note "rdsk" changed to "dsk") will result in an "inappropriate ioctl for device" error.

The device names within the /dev directory are typically symbolic links to much longer topological names in the /device directory. In Solaris cd/dvd/bd drives seem to be treated as disks and so are found in the /dev/rdsk directory. Tape drives appear in the /dev/rmt directory.

There is also a sgen (SCSI generic) driver which by default does not attach to any device. See the /kernel/drv/sgen.conf file to control what is attached. Any attached device will have a device name of the form /dev/scsi/c5t4d3 .

Listing available SCSI devices in Solaris seems to be a challenge. "Use the format command" advice works but seems a very dangerous way to list devices. [It does prompt again before doing any damage.] devfsadm -Cv cleans out the clutter in the /dev/rdsk directory, only leaving what is "live". The cfgadm -v command looks promising.

Examples

Some examples of storage device names of the supported operating systems :

Table 1. Device naming examples
device class
Linux
Windows
FreeBSD
Solaris
hard disk
/dev/sda
PD0
PhysicalDisk0
/dev/da0
/dev/rdsk/c5t4d3
hard disk partition
/dev/sda1
C:
/dev/da0s1a
/dev/rdsk/c5t4d3p0
CD/DVD/BD drive
/dev/sr0
/dev/scd0
CDROM0
/dev/cd1
/dev/rdsk/c5t4d2
tape drive
/dev/st0m
TAPE1
/dev/sa2
/dev/rmt/c5t4d1
pass-through
/dev/sg0
/dev/bsg/1:0:0:0
SCSI0:0,1,0 /dev/pass0
/dev/scsi/c5t4d3

Some operating systems allow SCSI commands to be sent directly to class device names using a pass-through interface. In Linux this is the case in the lk 2.6 series.

Please send corrections and clarifications to the author.


Doug Gilbert (dgilbert@interlog.com)
Last updated: 4th February 2012