Linux Device Name Convention

by

As with all Linux-like operating systems Linux uses device files to access all hardware (including disk drives). However, the naming conventions for attached storage devices varies somewhat between various Linux and Linux-like implementations. Here is how these device files are named under Linux.

Under Linux, the device files for disk drives appear in the /dev/ directory. The format for each file name depends on several aspects of the actual hardware and how it has been configured. The important points are as follows:

  • Device type
  • Unit
  • Partition

Device type

The first two letters of the device file name refer to the specific type of device. For disk drives, there are two device types that are most common:

  • sd — The device is SCSI-based
  • hd — The device is ATA-based

Unit

Following the two-letter device type are one or two letters denoting the specific unit. The unit designator starts with “a” for the first unit, “b” for the second, and so on. Therefore, the first hard drive on your system may appear as hda or sda.

Partition

The final part of the device file name is a number representing a specific partition on the device, starting with “1.” The number may be one or two digits in length, depending on the number of partitions written to the specific device. Once the format for device file names is known, it is easy to understand what each refers to. Here are some examples:

  • /dev/hda1 — The first partition on the first ATA drive
  • /dev/sdb12 — The twelfth partition on the second SCSI drive
  • /dev/sdad4 — The fourth partition on the thirtieth SCSI drive

 Whole-Device Access 

There are instances where it is necessary to access the entire device and not just a specific partition. This is normally done when the device is not partitioned or does not support standard partitions (such as a CD-ROM drive). In these cases, the partition number is omitted:

  • /dev/hdc — The entire third ATA device
  • /dev/sdb — The entire second SCSI device

Alternatives to Device File Names

Because adding or removing mass storage devices can result in changes to the device file names for existing devices, there is a risk of storage not being available when the system reboots. Here is an example of the sequence of events leading to this problem:

  1. The system administrator adds a new SCSI controller so that two new SCSI drives can be added to the system (the existing SCSI bus is completely full)
  2. The original SCSI drives (including the first drive on the bus: /dev/sda) are not changed in any way
  3. The system is rebooted
  4. The SCSI drive formerly known as /dev/sdanow has a new name, because the first SCSI drive on the new controller is now /dev/sda

File System Labels

These files have the ability to store a label — a character string that can be used to uniquely identify the data the file system contains. Labels can then be used when mounting the file system, eliminating the need to use the device name.

File system labels work well; however, file system labels must be unique system-wide. If there is ever more than one file system with the same label, you may not be able to access the file system you intended to. Also note that system configurations which do not use file systems (some databases, for example) cannot take advantage of file system labels.

File System Basics

Linux includes support for many popular file systems, making it possible to easily access the file systems of other operating systems.

This is particularly useful in dual-boot scenarios and when migrating files from one operating system to another.

The supported file systems include (but are not limited to):

  • EXT2
  • EXT3
  • NFS
  • ISO 9660
  • MSDOS
  • VFAT

The following sections explore the more popular file systems in greater detail.

EXT2

Until recently, the ext2 file system had been the standard file system for Linux. As such, it has received extensive testing and is considered one of the more robust file systems in use today.

However, there is no perfect file system, and ext2 is no exception. One problem that is commonly reported is that an ext2 file system must undergo a lengthy file system integrity check if the system was not cleanly shut down. While this requirement is not unique to ext2, the popularity of ext2, combined with the advent of larger disk drives, meant that file system integrity checks were taking longer and longer. Something had to be done.

EXT3

The ext3 file system builds upon ext2 by adding journaling capabilities to the already-proven ext2 codebase. As a journaling file system, ext3 always keeps the file system in a consistent state, eliminating the need for lengthy file system integrity checks.

This is accomplished by writing all file system changes to an on-disk journal, which is then flushed on a regular basis. After an unexpected system event (such as a power outage or system crash), the only operation that needs to take place prior to making the file system available is to process the contents of the journal; in most cases this takes approximately one second.

ISO 9660

In 1987, the International Organization for Standardization (known as ISO) released standard 9660. ISO 9660 defines how files are represented on CD-ROMs. Red Hat Enterprise Linux system administrators will likely see ISO 9660-formatted data in two places:

  • CD-ROMs
  • Files (usually referred to as ISO images) containing complete ISO 9660 file systems, meant to be written to CD-R or CD-RW media

The basic ISO 9660 standard is rather limited in functionality, especially when compared with more modern file systems. File names may be a maximum of eight characters long and an extension of no more than three characters is permitted. However, various extensions to the standard have become popular over the years, among them:

  • Rock Ridge — Uses some fields undefined in ISO 9660 to provide support for features such as long mixed-case file names, symbolic links, and nested directories (in other words, directories that can themselves contain other directories)
  • Joliet — An extension of the ISO 9660 standard, developed by Microsoft to allow CD-ROMs to contain long file names, using the Unicode character set

 MSDOS

Linux also supports file systems from other operating systems. As the name for the msdos file system implies, the original operating system supporting this file system was Microsoft’s MS-DOS®. As in MS-DOS, a Linux system accessing an msdos file system is limited to 8.3 file names. Likewise, other file attributes such as permissions and ownership cannot be changed. However, from a file interchange standpoint, the msdos file system is more than sufficient to get the job done.

VFAT

The vfat file system was first used by Microsoft’s Windows® 95 operating system. An improvement over the msdos file system, file names on a vfat file system may be longer than msdos’s 8.3. However, permissions and ownership still cannot be changed.

Mounting File Systems

To access any file system, it is first necessary to mount it. By mounting a file system, you direct Linux to make a specific partition (on a specific device) available to the system. Likewise, when access to a particular file system is no longer desired, it is necessary to umount it.

To mount any file system, two pieces of information must be specified:

  • A means of uniquely identifying the desired disk drive and partition, such as device file name, file system label, or devlabel-managed symbolic link
  • A directory under which the mounted file system is to be made available (otherwise known as a mount point)

The following section discusses mount points in more detail.

Mount Points

Unless you are used to Linux (or Linux-like) operating systems, the concept of a mount point will at first seem strange. However, it is one of the most powerful and flexible methods of managing file systems developed. With many other operating systems, a full file specification includes the file name, some means of identifying the specific directory in which the file resides, and a means of identifying the physical device on which the file can be found.

With Linux, a slightly different approach is used. As with other operating systems, a full file specification includes the file’s name and the directory in which it resides. However, there is no explicit device specifier.

The reason for this apparent shortcoming is the mount point. On other operating systems, there is one directory hierarchy for each partition. However, on Linux-like systems, there is only one directory hierarchy system-wide and this single hierarchy can span multiple partitions. The key is the mount point. When a file system is mounted, that file system is made available as a set of subdirectories under the specified mount point.

This apparent shortcoming actsually a strength. It means that seamless expansion of a Linux file system is possible, with every directory capable of acting as a mount point for additional disk space.

Seeing What is Mounted

In addition to mounting and unmounting disk space, it is possible to see what is mounted. There are several different ways of doing this:

  • Viewing /etc/mtab
  • Viewing /proc/mounts
  • Issuing the df command

 Viewing /etc/mtab
The file /etc/mtab is a normal file that is updated by the mount program whenever file systems are mounted or unmounted. Here is a sample /etc/mtab:

Each line represents a file system that is currently mounted and contains the following fields (from left to right):

  • The device specification
  • The mount point
  • The file system type
  • Whether the file system is mounted read-only (ro) or read-write (rw), along with any other mount options
  • Two unused fields with zeros in them (for compatibility with /etc/fstab)

Viewing /proc/mounts

  • The /proc/mountsfile is part of the proc virtual file system. As with the other files under /proc/, the mounts “file” does not exist on any disk drive in your Red Hat Enterprise Linux system.
  • In fact, it is not even a file; instead it is a representation of system status made available (by the Linux kernel) in file form.
  • Using the command cat /proc/mounts, we can view the status of all mounted file systems:
rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 /proc /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot ext3 rw 0 0 none /dev/pts devpts rw 0 0 /dev/sda4 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

 Issuing the df Command

While using /etc/mtab or /proc/mounts lets you know what file systems are currently mounted, it does little beyond that. Most of the time you are more interested in one particular aspect of the file systems that are currently mounted — the amount of free space on them.

For this, we can use the df command. Here is some sample output from df:

 Filesystem 1k-blocks Used Available Us

Several differences from /etc/mtab and /proc/mount are immediately obvious:

  • An easy-to-read heading is displayed
  • With the exception of the shared memory file system, only disk-based file systems are shown
  • Total size, used space, free space, and percentage in use figures are displayed

That last point is probably the most important because every system administrator eventually has to deal with a system that has run out of free disk space. With df it is very easy to see where the problem lies.