How Linux Reads CD-ROMs Using ISO 9660

This article explains how the Linux operating system accesses and reads data from CD-ROM media formatted with the ISO 9660 file system. It details the interaction between user space and kernel space, covering the role of the block device driver, the Virtual File System (VFS), the parsing of ISO 9660 volume descriptors, and the integration of POSIX extensions like Rock Ridge.

Hardware Detection and the Block Layer

When a CD-ROM is inserted into an optical drive, the Linux kernel detects the device through the SCSI or ATA/ATAPI subsystem. Optical drives are assigned device nodes in the /dev directory, typically identified as /dev/sr0 or /dev/cdrom.

Optical discs physically store data in sectors, with ISO 9660 utilizing a standard logical sector size of 2,048 bytes (2 KB). The optical device driver provides an interface for reading these raw 2 KB blocks sequentially or via random access, exposing the medium to the kernel's block layer.

The Mounting Process and the VFS

To access the files, the user or an automount daemon issues a mount request:

mount -t iso9660 /dev/sr0 /mnt/cdrom

The system call reaches the Virtual File System (VFS), the kernel abstraction layer that allows diverse file systems to present a uniform interface to user-space applications. The VFS identifies the target file system as iso9660 and delegates the operation to the kernel's isofs driver.

Parsing ISO 9660 Metadata

Once invoked, the isofs driver inspects the disk layout to build an in-memory representation of the directory hierarchy:

1. System Area: The first 16 sectors (sectors 0 to 15, bytes 0 to 32,767) are reserved for system use, such as boot codes, and are skipped by the file system driver.
2. Volume Descriptor Set: Reading begins at sector 16 (byte 32,768). The kernel scans for the Primary Volume Descriptor (PVD), which contains critical metadata including:
   • System and volume identifiers
   • Logical block size (typically matching the 2,048-byte sector)
   • Total volume space in blocks
   • The Root Directory Record
3. Supplementary Descriptors: The kernel also checks for Supplementary Volume Descriptors (SVD). This enables detection of extensions like Joliet (used for Unicode and long filenames) or El Torito (used for bootable discs).

Handling Directory Records and Rock Ridge Extensions

The Root Directory Record embedded in the PVD points to the physical block where the root directory structure begins. Directory entries in ISO 9660 are variable-length records containing:

• The starting block (extent) of the file or subdirectory
• File length in bytes
• Basic flags (such as whether the entry is a directory or a file)
• File identifier (name)

Standard ISO 9660 restricts filenames to an 8.3 format or 31 characters using uppercase letters, digits, and underscores, without POSIX-compliant attributes like file permissions, ownership, or symbolic links.

To solve this, Linux uses the Rock Ridge Interchange Protocol (RRIP):

• Rock Ridge embeds standard POSIX metadata inside the System Use Field (an unused space at the end of each directory record).
• The Linux isofs driver parses these fields to extract standard UNIX file permissions, user and group IDs (UID/GID), symlinks, and full-length, case-sensitive filenames.
• If Rock Ridge is present, Linux defaults to using these records to populate its inode structures.

Executing the Read Operation

When an application reads a file (e.g., executing cat /mnt/cdrom/document.txt):

1. Path Resolution: The VFS looks up the path by querying the isofs driver, which traverses the directory records starting from the root directory block to find the matching entry.
2. Block Mapping: Once the entry is located, isofs maps the file's offset to the physical sector numbers on the disc. Because ISO 9660 allocates files in contiguous blocks, this translation involves calculating the starting sector plus the offset divided by the sector size.
3. Page Cache Integration: The VFS checks the Linux page cache. If the requested data blocks are not cached in RAM, the kernel constructs an I/O request (a bio structure) targeting the specific logical block addresses.
4. Data Retrieval: The block layer dispatches the request to the underlying ATAPI/SCSI driver, which sends read commands directly to the drive hardware. The drive reads the sectors and transfers the raw data into system memory via Direct Memory Access (DMA).
5. Return to User Space: The kernel marks the data pages as valid in the page cache, and the read() system call copies the requested bytes into the application's memory buffer. Subsequent reads of the same data are served directly from RAM without spinning up the optical drive.