Neutrino provides a rich variety of filesystems. Like most service-providing processes in the OS, these filesystems execute outside the kernel; applications use them by communicating via messages generated by the shared-library implementation of the POSIX API.

The filesystems are resource managers as described in this book. Each filesystem adopts a portion of the pathname space and provides filesystem services through the standard POSIX API (open(), close(), read(), write(), lseek(), etc.).

This implementation means that:

• Filesystems may be started and stopped dynamically.
• Multiple filesystems may run concurrently.
• Applications are presented with a single unified pathname space and interface, regardless of the configuration and number of underlying filesystems.

The many filesystems available can be categorized into the following classes:

Image

A special filesystem that presents the modules in the image and is always present.

Block

Traditional filesystems that operate on block devices like hard disks and CD-ROM drives. This includes the QNX®, DOS, and CD-ROM filesystems.

Flash

Non-block-oriented filesystems designed explicitly for the characteristics of flash memory devices. This includes the flash filesystem.

Network

Filesystems that provide network file access to the filesystems on remote host computers. This includes the NFS and CIFS (SMB) filesystems.

Filesystems as shared libraries

Since it's common to run many filesystems under Neutrino,^they have been designed as a family of drivers and shared libraries to maximize code reuse. This means the cost of adding an additional filesystem is typically smaller than might otherwise be expected.

Once an initial filesystem is running, the incremental memory cost for additional filesystems is minimal, since only the code to implement the new filesystem protocol would be added to the system.

The various filesystems are layered as follows:

Neutrino filesystem layering. Note that the procnto process automatically provides an image filesystem and a RAM filesystem.

As shown in this diagram, the Filesystems and io-blk are implemented as shared libraries (essentially passive blocks of code resident in memory), while the driver is the executing process that calls into the libraries. In operation, the driver process starts first and invokes the block-level shared library. The filesystem shared libraries may be dynamically loaded later to provide filesystem interfaces and services.

Note that this is the opposite of many systems, which implement the filesystem as the primary entity that then loads drivers to talk to disk devices. This reversal of oles in Neutrino provides interesting capabilities.

A "filesystem" shared library implements a filesystem protocol or "personality" on a set of blocks on a physical disk device. The filesystems aren't built into the OS kernel; rather, they're dynamic entities that can be loaded or unloaded on demand.

For example, a removable storage device (PCCard flash card, floppy disk, removable cartridge disk, etc.) may be inserted at any time, with any of a number of filesystems stored on it. While the hardware the driver interfaces to is unlikely to change dynamically, the on-disk data structure could vary widely. The dynamic nature of the filesystem copes with this very naturally.

io-blk.so

Most of the filesystem shared libraries ride on top of the Block I/O module (io-blk). This module also acts as a resource manager and exports a block-special file for each physical device. For a system with two hard disks the default files would be:

/dev/hd0

First hard disk

/dev/hd1

Second hard disk

These files represent each raw disk and may be accessed using all the normal POSIX file primitives (open(), close(), read(), write(), lseek(), etc.). The io-blk module in Neutrino can support a 64-bit offset on seek, allowing access to disks with greater than 18 exabytes (2^63 bytes).

Partitions

Neutrino complies with the de facto industry standard for partitioning a disk. This allows a number of filesystems to share the same physical disk. Each partition is also represented as a block-special file, with the partition type appended to the filename of the disk it's located on. In the above "two-disk" example, if the first disk had a QNX® partition and a DOS partition, while the second disk had only a QNX® partition, then the default files would be:

/dev/hd0

First hard disk

/dev/hd0t6

DOS partition on first hard disk

/dev/hd0t77

QNX® partition on first hard disk

/dev/hd1

Second hard disk

/dev/hd1t77

QNX® partition on second hard disk

The following list shows some of the partition types currently used:

Buffer cache

The io-blk shared library implements a buffer cache that all filesystems inherit. The buffer cache attempts to store frequently accessed filesystem blocks in order to minimize the number of times a system has to perform a physical I/O to the disk.

Read operations are synchronous; write operations are usually asynchronous. When an application writes to a file, the data enters the cache, and the Filesystem Manager immediately replies to the client process to indicate that the data has been written. The data is then written to the disk as soon as possible.

Critical filesystem blocks such as bitmap blocks, directory blocks, extent blocks, and inode blocks are written immediately and synchronously to disk (these critical blocks bypass the normal write mechanism, including the elevator seeking).

Applications can modify write behavior on a file-by- file basis. For example, a database application can cause all writes for a given file to be performed synchronously. This would ensure a high level of file integrity in the face of potential hardware or power problems that might otherwise leave a database in an inconsistent state.

Filesystem limitations

POSIX defines the set of services a filesystem must provide. However, not all filesystems are capable of delivering all those services. The following chart highlights some of the POSIX-defined capabilities and indicates if the filesystems support them:

• * VFAT or FAT32 (e.g. Windows 95).
• ** With Rock Ridge extensions.
• ⁺ 255-character filename lengths used by VFAT or FAT32 (e.g. Windows 95).
• ⁺⁺ Limited by remote filesystem.

Every Neutrino system image that includes the Process anager/Microkernel (procnto) provides a simple read-only filesystem that presents the set of files built into the OS image.

Since this image may include both executables and data files, this filesystem is sufficient for many embedded systems. If additional filesystems are required, they would be placed as modules within the image where they can be started as needed.

Every QNX® system that includes the Process Manager/Microkernel (procnto) also provides a simple RAM-based "filesystem" that allows read/write files to be placed under /dev/shmem.

This RAM filesystem finds the most use in tiny embedded systems where persistent storage across reboots isn't required, yet where a small, fast, temporary-storage filesystem is called for.

The filesystem comes for free with procnto and doesn't require any setup. You can simply create files under /dev/shmem and grow them to any size (depending on RAM resources).

Although the RAM filesystem itself doesn't support hard or soft links, you can create a link to it by utilizing Process Manager links. For example, you could create a link to a RAM-based /tmp directory:

ln -sP /dev/shmem /tmp

This tells procnto to create a Process Manager link to /dev/shmem known as "/tmp." Application programs can then open files under /tmp as if it were a normal filesystem.

The QNX® filesystem (fs-qnx) is a high-performance filesystem that shares the same on-disk structure as QNX® 4.

The QNX® filesystem implements an extremely robust design, utilizing an extent-based, bitmap allocation scheme with fingerprint control structures to safeguard against data loss and to provide easy recovery. Features include:

• extent-based POSIX filesystem
• robustness: all sensitive filesystem info is written through to disk
• on-disk "signatures" and special key information to allow fast data recovery in the event of disk damage
• 48-character filenames
• multi-threaded design
• client-driven priority
• same disk format as QNX® 4 filesystem

Disk structure

The QNX® filesystem consists of the following components found at the beginning of its partition:

• loader block
• root block
• bitmap
• root directory
• other directories, files, free blocks, etc.

These structures are created when the filesystem is initialized with the dinit utility.

Loader block

This is the first physical block of a disk partition. This block contains the code that is loaded and then executed by the BIOS of the computer to load an OS from the partition. If a disk hasn't been partitioned (e.g. a floppy diskette), this block is the first physical block on the disk.

Root block

The root block is structured as a standard directory. It contains inode information for these special files:

• the root directory of the filesystem (/)
• /.inodes
• /.boot
• /.altboot

The files /.boot and /.altboot contain images of the operating system that can be loaded by the QNX® bootstrap loader.

Normally, the QNX® loader loads the OS image stored in the /.boot file. But if the /.altboot file isn't empty, you'll be given the option to load the image stored in the /.altboot file.

Bitmap

To allocate space on a disk, QNX® uses a bitmap stored in the /.bitmap file. This file contains a map of all the blocks on the disk, indicating which blocks are used. Each block is represented by a bit. If the value of a bit is 1, its corresponding block on the disk is in use.

Root directory

The root directory of a partition behaves as a normal directory file with two exceptions:

• Both "dot" (.) and "dot dot" (..) are links to the same inode information, namely the root directory inode in the root block.
• The root directory always has entries for the /.bitmap, /.inodes, /.boot, and /.altboot files. These entries are provided so programs that report information on filesystem usage will see the entries as normal files.

Extents

In the QNX® filesystem, regular files and directory files are stored as a sequence of extents. An extent is a contiguous sequence of blocks on disk.

Files that have only a single extent store the extent information in the directory entry. If more than one extent is needed to hold the file, the extent location information is stored in one or more linked extent blocks. Each extent block can hold location information for up to 60 extents.

A file consisting of multiple consecutive regions or extents on a disk.

Extending files

When the QNX® filesystem needs to extend a file, it uses the bitmap to see if it can extend the file contiguously on disk. If not, it tries to allocate a new extent. This may require allocating a new extent block as well. When an extent is allocated or grown, the filesystem may over-allocate space under the assumption that the process will continue to write and fill the extra space. When the file is closed any extra space will be returned.

This design ensures that when files are written, even several files at one time, they are as contiguous as possible. Since most hard disk drives implement track caching, this not only ensures that files are read as quickly as possible from the disk hardware, but also serves to minimize the fragmentation of data on disk.

Links and inodes

File data is stored distinctly from its name and can be referenced by more than one name. Each filename, called a link, points to the actual data of the file itself. (There are actually two kinds of links: hard links, which we refer to simply as "links," and symbolic links. Symbolic links are described in the next section.)

In order to support links for each file, the filename is separated from the other information that describes a file. The non-filename information is kept in a storage table called an inode (for "information node").

If a file has only one link (i.e. one filename), the inode information (i.e. the non-filename information) is stored in the directory entry for the file. If the file has more than one link, the inode is stored as a record in a special file named /.inodes - the file's directory entry will point to the inode record.

Note that you can create a link to a file only if the file and the link are in the same filesystem.

The same file is referenced by two links named "more" and "less."

There are two other situations in which a file can have an entry in the /.inodes file:

• If a file's filename is longer than 16 characters, the inode information is stored in the /.inodes file, making room for a 48-character filename in the directory entry.
• If a file has had more than one link and all links but one have been removed, the file continues to have a separate /.inodes file entry. This is done because the overhead of searching for the directory entry that points to the inode entry would be prohibitive (there are no back links from inode entries to directory entries).

Removing links

When a file is created, it is given a link count of one. As links to the file are added, this link count is incremented; as links are removed, the link count is decremented. The disk space occupied by the file data isn't freed and marked as unused in the bitmap until its link count goes to zero and all programs using the file have closed it. This allows an open file to remain in use, even though it has been completely unlinked. This behavior is part of that stipulated by POSIX and common UNIX practice.

Directory links

Although you can't create hard links to directories, each directory has two hard-coded links already built in:

• .  ("dot")
• ..  ("dot dot")

The filename "dot" refers to the current directory; "dot dot" refers to the previous directory in the hierarchy.

Note that if there's no predecessor, "dot dot" also refers to the current directory. For example, the "dot dot" entry of "/" is simply "/"-you can't go further up the path.

Symbolic links

A symbolic link is a special file that usually has a pathname as its data. When the symbolic link is named in an I/O request-by open(), for example-the link portion of the pathname is replaced by the link's "data" and the path is re-evaluated.

Symbolic links are a flexible means of pathname indirection and are often used to provide multiple paths to a single file. Unlike hard links, symbolic links can cross filesystems and can also create links to directories.

In the following example, the directories /net/node1/usr/fred and /net/node2/usr/barney are linked even though they reside on different filesystems-they're even on different nodes (see the following diagram). This couldn't be done using hard links:

/net/node1/usr/fred -->  /net/node2/usr/barney

Note how the symbolic link and the target directory need not share the same name. In most cases, you use a symbolic link for linking one directory to another directory. However, you can also use symbolic links for files, as in this example:

/net/node1/usr/eric/src/test.c --> /net/node1/usr/src/game.c

Symbolic links can be used for files and directories anywhere throughout the network.

Remember that removing a symbolic link acts only on the link, not the target.

Several functions operate directly on the symbolic link. For these functions, the replacement of the symbolic element of the pathname with its target is not performed. These functions include unlink() (which removes the symbolic link), lstat(), and readlink().

Since symbolic links can point to directories, incorrect configurations can result in problems such as circular directory links. To recover from circular references, the system imposes a limit on the number of hops; this limit is defined as SYMLOOP_MAX in the <limits.h> include file.

Filesystem robustness

The QNX® filesystem achieves high throughput without sacrificing reliability. This has been accomplished in several ways.

While most data is held in the buffer cache and written after only a short delay, critical filesystem data is written immediately. Updates to directories, inodes, extent blocks, and the bitmap are forced to disk to ensure that the filesystem structure on disk is never corrupt (i.e. the data on disk should never be internally inconsistent).

Sometimes all of the above structures must be updated. For example, if you move a file to a directory and the last extent of that directory is full, the directory must grow. In such cases, the order of operations has been carefully chosen such that if a catastrophic failure occurs when the operation is only partially completed (e.g. a power failure), the filesystem, upon rebooting, would still be "intact." At worst, some blocks may have been allocated, but not used. You can recover these for later use by running the chkfsys utility.

Filesystem recovery

Even in the best systems, true catastrophes such as these may happen:

• Bad blocks may develop on a disk because of power surges or brownouts.
• A naive or malicious user with access to superuser privileges might reinitialize the filesystem (via the dinit utility).
• An errant program (especially one run in a non-QNX® environment) may ignore the disk partitioning information and overwrite a portion of the QNX® partition.

To recover as many files as possible if such events occur, unique "signatures" have been written on the disk to aid in the automatic identification and recovery of the critical filesystem pieces. The inodes file (/.inodes), as well as each directory and extent block, all contain unique patterns of data that a "fixer" program could scan for.

The DOS Filesystem, fs-dos, provides transparent access to DOS disks, so you can treat DOS filesystems as though they were POSIX filesystems. This transparency allows processes to operate on DOS files without any special knowledge or work on their part.

The structure of the DOS filesystem on disk is old and inefficient, and lacks many desirable features. Its only major virtue is its portability to DOS and Windows environments. You should choose this filesystem only if you need to transport DOS files to other machines that require it. Consider using the QNX® Filesystem alone if DOS file portability isn't an issue or in conjunction with the DOS Filesystem if it is.

If there's no DOS equivalent to a POSIX feature, fs-dos will either return an error or a reasonable default. For example, an attempt to create a link() will result in the appropriate errno being returned. On the other hand, if there's an attempt to read the POSIX times on a file, fs-dos will treat any of the unsupported times the same as the last write time.

DOS version support

The fs-dos program supports both floppies and hard disk partitions from DOS version 2.1 to Windows 98 with long filenames.

DOS text files

DOS terminates each line in a text file with two characters (CR/LF), while POSIX (and most other) systems terminate each line with a single character (LF). Note that fs-dos makes no attempt to translate text files being read. Most utilities and programs won't be affected by this difference.

Note also that some very old DOS programs may use a Ctrl-Z (^Z) as a file terminator. This character is also passed through without modification.

QNX®-to-DOS filename mapping

In DOS, a filename cannot contain any of the following characters:

/ \ [ ] : * | + = ; , ?

An attempt to create a file that contains one of these invalid characters will return an error. DOS (8.3 format) also expects all alphabetical characters to be uppercase, so fs-dos maps these characters to uppercase when creating a filename on disk. But it maps a filename to lowercase when returning a filename to a QNX® application, so that QNX® users and programs can always see and type lowercase.

Handling filenames

You can specify how you want fs-dos to handle long filenames (via the lfn=lfn_mode option):

• Ignore them - display/create only 8.3 filenames.
• Show them - if filenames are longer than 8.3 or if mixed case is used.
• Always create both short and long filenames.

If you use the ignore option, you can specify whether or not to truncate filename characters beyond the 8.3 limit.

DOS volume labels

DOS uses the concept of a volume label, which is an actual directory entry in the root of the DOS filesystem. To distinguish between the volume label and an actual DOS directory, fs-dos reports the volume label as a name-special file and will optionally place an equal sign (=) as the first character of the volume name.

DOS-QNX® permission mapping

DOS doesn't support all the permission bits specified by POSIX. It has a READ_ONLY bit in place of separate READ and WRITE bits; it doesn't have an EXECUTE bit. When a DOS file is created, the DOS READ_ONLY bit will be set if all the POSIX WRITE bits are off. When a DOS file is accessed, the POSIX READ bit is always assumed to be set for user, group, and other.

Since you can't execute a file that doesn't have EXECUTE permission, fs-dos has an option that lets you specify how to handle the POSIX EXECUTE bit for executables.

File ownership

Although the DOS file structure doesn't support user IDs and group IDs, fs-dos (by default) won't return an error code if an attempt is made to change them. An error isn't returned because a number of utilities attempt to do this and failure would result in unexpected errors. The approach taken is "you can change anything to anything since it isn't written to disk anyway."

The posix option lets you set stricter POSIX checks and enable POSIX emulation. For example, in POSIX mode, an error of EINVAL is flagged for attempts to do any of the following:

• Set the user ID or group ID to something other than the default (root).
• Remove an r (read) permission.
• Set an s (set ID on execution) permission.

The CD-ROM filesystem provides transparent access to CD-ROM media, so you can treat CD-ROM filesystems as though they were POSIX filesystems. This transparency allows processes to operate on CD-ROM files without any special knowledge or work on their part.

The fs-cd manager implements the ISO 9660 standard as well as a number of extensions, including Rock Ridge (RRIP), Joliet (Microsoft), and multisession (Kodak Photo CD, enhanced audio).

The flash filesystem drivers implement a POSIX- compatible filesystem on flash memory devices. The flash filesystem drivers are standalone executables that contain both the flash filesystem code and the flash device code. There are versions of the flash filesystem driver for different embedded systems hardware as well as PCMCIA memory cards.

The naming convention for the drivers is devf-system, where system describes the embedded system. For example, the devf-800fads driver is for the 800FADS PowerPC evaluation board.

To find out what flash devices we currently support, please refer to the following sources:

• the boards and mtd directories under /usr/src/nto/flash.
• the QSSL web site (www.qnx.com).

Customization

Along with the pre-built flash filesystem drivers, we provide the libraries and source code needed to build custom flash filesystem drivers for different embedded systems. For information on how to do this, see the chapter on customizing a flash filesystem driver in the Building Embedded Systems book.

Organization

The flash filesystem drivers support one or more logical flash drives. Each logical drive is called a socket, which consists of a contiguous and homogeneous region of flash memory. For example, in a system containing two different types of flash device at different addresses, where one flash device is used for the boot image and the other for the flash filesystem, each flash device would appear in a different socket.

Each socket may be divided into one or more partitions. Two types of partitions are supported: raw partitions and flash filesystem partitions.

Raw partitions

A raw partition in the socket is any partition that doesn't contain a flash filesystem. The flash filesystem driver doesn't recognize any filesystem types other than the flash filesystem. A raw partition may contain an image filesystem or some application-specific data.

The flash filesystem will make accessible through a raw mountpoint (see below) any partitions on the flash that aren't flash filesystem partitions. Note that the flash filesystem partitions are available as raw partitions as well.

Filesystem partitions

A flash filesystem partition contains the POSIX- compatible flash filesystem, which uses a QNX® proprietary format to store the filesystem data on the flash devices. This format isn't compatible with either the Microsoft FFS2 or PCMCIA FTL specification.

The flash filesystem allows files and directories to be freely created and deleted. It recovers space from deleted files using a background reclaim thread.

Mountpoints

When you start the flash filesystem driver, it will by default mount any partitions it finds in the socket. Note that you can specify the mountpoint using mkefs or flashctl (e.g. /flash).

Features

The flash filesystem supports many advanced features, such as POSIX compatibility, multiple threads, background reclaim, fault recovery, transparent decompression, and endian-awareness.

POSIX

The flash filesystem supports the standard POSIX functionality (including long filenames, access privileges, random writes, truncation, and symbolic links) with the following exceptions:

• You can't create hard links.
• You can't rename files across directories.
• You can share files, but not directories.
• Access times aren't supported (but file modification times and attribute change times are).

These design compromises allow the flash filesystem to remain small and simple, yet include most features normally found with block device filesystems.

Background reclaim

The flash filesystem stores files and directories as a linked list of extents, which are marked for deletion as they're deleted or updated. Blocks to be reclaimed are chosen using a simple algorithm that finds the block with the most space to be reclaimed while keeping level the amount of wear of each individual block. This wear-leveling reduces the MTBF (mean time between failure) of the flash devices.

By default, the reclaim process is performed when there isn't enough free space or if the -b priority is selected (in which case the reclaim is performed in the background by a low-priority thread). The reclaim thread first copies the contents of the reclaim block to an empty spare block, which then replaces the reclaim block. The reclaim block is then erased. Unlike rotating media, proximity of data isn't a factor with a flash filesystem, so data can be scattered on the media without loss of performance.

Fault recovery

The flash filesystem has been designed to minimize corruption due to accidental loss-of-power faults. Updates to extent headers and erase block headers are always executed in carefully scheduled sequences. These sequences allow the recovery of the flash filesystem's integrity in the case of data corruption. With properly designed hardware for power faults, flash write transactions can be guaranteed to be finished when a power fault occurs (as long as there's just enough power left to commit a 10-microsec write cycle).

When the flash filesystem driver is started, it scans the state of every header on the media (in order to validate its integrity) and takes appropriate action, ranging from a simple block reclamation to the erasure of dangling extent links. This process is merged with the normal mount procedure of the flash filesystem in order to achieve optimal bootstrap timings.

Transparent decompression

The flash filesystem supports transparent decompression of files that have been compressed using the flashzip utility. This utility uses the well-known zip algorithm to compress files - this can reduce most executables to about a third of their uncompressed size.

Compressed files can be manipulated with standard utilities such as cp or ftp - they an display their compressed and uncompressed size with the ls utility if used with the proper mountpoint. These features make the management of a compressed flash filesystem seamless to a systems designer.

Flash errors

As flash hardware wears out, its write state-machine may find that it can't write or erase a particular bit cell. When this happens, the error status is propagated to the flash driver so it can take proper action (i.e. mark the bad area and try to write/erase in another place).

This error-handling mechanism is transparent. Note that after several flash errors, all writes and erases that fail will eventually render the flash read-only. Fortunately, this situation shouldn't happen before several years of flash operation. Check your flash specification and analyze your application's data flow to flash in order to calculate its potential longevity or MTBF.

Endian awareness

The flash filesystem is endian-aware, making it portable across different platforms. The optimal approach is to use the mkefs utility to select the target's endian-ness.

Utilities

The flash filesystem supports all the standard POSIX utilities such as ls, mkdir, rm, ln, mv, and cp. There are also some QNX® utilities for managing the flash filesystem:

flashctl

Erase, format, and mount flash partitions.

flashzip

Compress files.

mkefs

Create flash filesystem image files.

System calls

The flash filesystem supports all the standard POSIX I/O functions such as open(), close(), read(), and write(). Special functions such as erasing are supported using the devctl() function.

The Network File System (NFS) allows a client workstation to perform transparent file access over a network. It allows a client workstation to operate on files that reside on a server across a variety of operating systems. Client file access calls are converted to NFS protocol requests, and are sent to the server over the network. The server receives the request, performs the actual filesystem operation, and sends a response back to the client.

The Network File System operates in a stateless fashion by using remote procedure calls (RPC) and TCP/IP for its transport. Therefore, to use fs-nfs2 you'll also need to run the TCP/IP client for Neutrino.

Any POSIX limitations in the remote server filesystem will be passed through to the client. For example, the length of filenames may vary across servers from different operating systems. NFS (version 2) limits filenames to 255 characters; mountd (version 1) limits pathnames to 1024 characters.

Although NFS (version 2) is older than POSIX, it was designed to emulate UNIX filesystem semantics and happens to be relatively close to POSIX.

Formerly known as SMB, the Common Internet File System (CIFS) allows a client workstation to perform transparent file access over a network to a Windows 98 or NT system, or a UNIX system running an SMB server. Client file access calls are converted to CIFS protocol requests and are sent to the server over the network. The server receives the request, performs the actual filesystem operation, and sends a response back to the client.

The CIFS protocol makes no attempt to conform to POSIX.

The fs-cifs module uses TCP/IP for its transport. Therefore, to use fs-cifs (SMBfsys in QNX® 4), you'll also need to run the TCP/IP client for Neutrino.

<< Previous | Index | Next >>