18 Setting Up Other File Systems

This chapter covers the following topics:

• Introduction
• Partitioning the pathname space
• Using CIFS to access remote hard disks
• Using the DOS filesystem manager
• Using the QNX 4 filesystem manager
• Using flash filesystems
• Using the NFS filesystem
• Using a CD-ROM filesystem
• Using a Linux Ext2 filesystem

Introduction

QNX 6 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.

Most of these filesystems are resource managers (see "What is a Resource Manager?"). 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.

Filesystem classes

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 4, DOS, and CD-ROM filesystems.

Flash

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

Network

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

Package

Virtual filesystems that present custom views of selected files and directories to a client.

Filesystems as shared libraries

Since it's common to run many filesystems under QNX 6, they have been designed as a family of drivers and shared libraries to maximize code reuse. Most of the filesystem shared libraries ride on top of the shared object that provides block I/O support, io-blk.so. This shared object supports the block-oriented drivers, devb-*, loading specific filesystem drivers as necessary. This module also acts as a resource manager and exports a block-special file for each physical device. E.g. for a system with two hard disks, the default files would refer to:

• The first disk as /dev/hd0.
• The second disk as /dev/hd1

These files represent each raw disk and may be accessed using all the normal POSIX file primitives.

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 roles in QNX 6 provides interesting capabilities.

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.

Partitioning the pathname space

Use the fdisk utility (see Utilities Reference) to partition a hard disk. The partition information matches that used by DOS. The information is kept on the first physical block on the disk. This utility can be run only by root or users with read/write permission for the block special file concerned.

Create a single partition for a single operating system type; create multiple partitions for multiple operating systems or to provide faster performance with smaller disks.

Using CIFS to access remote hard disks

CIFS, the Common Internet File System protocol, 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 then sends a response back to the client. CIFS runs on top of TCP/IP and uses DNS.

The fs-cifs filesystem manager (see Utilities Reference) is a CIFS (SMB) client operating over TCP/IP. To use it, you must have an SMB server and a valid login on that server. The fs-cifs utility is primarily intended for use as a client with Windows NT machines, although it also works with any SMB server, e.g. OS/2 Peer, LAN Manager, and SAMBA.

The fs-cifs filesystem manager requires a TCP/IP transport layer, such as the one provided by io-net with npm-ttcpip.so.

Using the DOS filesystem manager

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

The fs-dos.so shared object (see Utilities Reference) lets you mount DOS filesystems (FAT12, FAT16, and FAT32) under QNX 6. This shared object is automatically loaded by the devb-* drivers when mounting a DOS FAT filesystem. If you want to read and write to DOS floppy disks, mount it by typing something like this:

	mount -t dos /dev/fd0 /fd 

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. Choose this filesystem only if you need to transport DOS files to other machines that require it. If DOS file portability isn't an issue, use the QNX 6 filesystem alone.

DOS version support

The fs-dos.so shared object enables you to partition floppy disks and hard disks 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 systems like QNX 6 terminate each line with a single character (LF). The fs-dos.so DOS filesystem doesn't translate text files being read and most utilities and programs won't be affected by this difference. Some very old DOS programs may use 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:

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

If you try to create a file that contains one of these invalid characters, DOS will return an error. Also, the DOS 8.3 format expects all alphabetical characters to be uppercase, so fs-dos.so 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 6 application, so that QNX 6 users and programs can always see and type lowercase.

Handling filenames

You can specify how you want fs-dos.so to handle long filenames using its lfn option; you can choose to either:

• Ignore long filename and display or create only 8.3 filenames.
• Show them, if filenames are longer than 8.3 or if mixed case is used (default).
• Always create both short and long filenames.

You can specify how DOS 8.3 files names will be displayed using the sfn option; you can choose to display 8.3 filenames:

• All in lower case, e.g. file.c (default).
• All in upper case, e.g. FILE.C.
• In lower case with the first letter capitalized, e.g. File.c.

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.so reports the volume label according to its volabel option you choose. You can choose to:

• Ignore the volume label.
• Display the volume label as a name-special file.
• Display the volume label as a name-special file with an equal sign (=) as the first character of the volume name (default).

DOS-QNX permission mapping

DOS doesn't support all the permission bits specified by POSIX. DOS 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.so 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.so, 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 posix option of fs-dos.so lets you set stricter checks enabling POSIX emulation. If you set the posix option, you get the following benefits:

• The . and .. directory entries are created in the root directory.
• The directory size is calculated.
• The number of links in a directory is calculated, based on its subdirectories.
• An error is flagged if an attempt is made to either set the usedID or groupID to anything other than their default values, remove a read permission, or set an s permission (set ID on execution).

For more information

See fs-dos.so in the Utilities Reference and the Filesystem chapter of System Architecture for more information on the DOS filesystem manager.

Using the QNX 4 filesystem manager

The fs-qnx.so shared object supports QNX 4 filesystems. It is automatically loaded by the devb-* drivers when mounting a QNX 4 filesystem. Features include:

• POSIX-based.
• Disk storage of sensitive filesystem information.
• Fast data recovery in the event of disk damage.
• 48-character filenames.

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.

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.

You can create a hard link to a file only if the file and the link are in the same filesystem. Symbolic links do not have this restriction.

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. The new path has nothing to do with the current working directory, it depends solely on the string entered when the link was created.

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 link directories.

You normally use a symbolic link for linking one directory to another, but they can also link files.

For more information

See fs-qnx.so in the Utilities Reference and the Filesystem chapter of System Architecture for more information on the QNX 4 filesystem manager.

Using flash filesystems

QNX 6 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.

Drivers for the flash filesystem are named devf-*, where * represents the target embedded system; e.g. devf-800fads is the driver for the 800FADS PowerPC evaluation board.

See the QNX web site for a list of currently supported flash devices.

Customization

Along with the pre-built flash filesystem drivers, QNX provides the libraries and source code needed to build custom flash filesystem drivers for different embedded systems. For information on how to do this, see "Customizing the Flash Filesystem" in Building Embedded Systems.

Organization

The flash filesystem drivers support one or more logical flash drives. Each logical drive, called a socket, consists of a contiguous and homogeneous region of flash memory. E.g. 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.

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.

Mountpoints

When you start the flash filesystem driver, it will mount any partitions it finds in the socket by default. Note that you can specify the mountpoint using the mount attribute of mkefs or the -n option of flashctl (see Utilities Reference for more information on these two utilities). E.g:

Mountpoint:	Description:
/dev/fsX	raw mountpoint socket X
/dev/fsXpY	raw mountpoint socket X partition Y
/fsXpY	filesystem mountpoint socket X partition Y
/fsXpY/.cmp	filesystem compressed mountpoint socket X partition Y

Features

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

Utilities

The flash filesystem supports all the standard POSIX utilities such as ls, mkdir, rm, ln, mv, and cp. There are also some other QNX utilities you can use to manage the flash filesystem, e.g.

To:	Use this utility
Erase, format, and mount flash partitions	flashctl
Compress files	flashzip
Create flash filesystem image files	mkefs

For more information

For more information on the way QNX 6 handles flash filesystems, see:

• The mkefs and flashctl utilities in Utilities Reference.
• The Filesystem chapter of System Architecture.

· Building Embedded Systems.

Using the NFS filesystem

[Author's Comments: (@@content from the What is NFS? chapter of the TCP/IP 5.0 User's Guide fs-* network filesystem drivers What are network file system drivers? What is NFS? How do I use it? (chapter of the TCP/IP 5.0 user guide, but verify applicable parts]

The Network File System (NFS) 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 fs-nfs2 filesystem manager is an NFS 2 client operating over TCP/IP. To use it, you must have an NFS server and you must be running a TCP/IP transport layer such as that provided by io-net with npm-ttcpip.so.

You can also create mountpoints by specifying nfs as the type option of the mount command.

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

For more information

See fs-nfs2 in the Utilities Reference and the Filesystem chapter of System Architecture for more information on the NFS filesystem manager.

Using a CD-ROM filesystem

The CD-ROM filesystem provided in RTP 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.so shared object provides filesystem support for the ISO 9660 standard as well as a number of extensions, including Rock Ridge (RRIP), Joliet (Microsoft), and multisession (Kodak Photo CD, enhanced audio). This shared object is automatically loaded by the devb-* drivers when mounting an ISO-9660 filesystem.

For more information

See fs-cd.so in the Utilities Reference and the Filesystem chapter of System Architecture for more information on the ISO-9660 filesystem manager.

Using a Linux Ext2 filesystem

The Ext 2 filesystem provided in RTP provides transparent access to Linux disk partitions. Not all Ext2 features are supported; features not currently supported include:

• sparse superblocks
• file fragments (sub-block allocation)
• large files greater than 2 GB
• filetype extension
• compression
• b-tree directories

The fs-ext2.so shared object provides filesystem support for Ext2. This shared object is automatically loaded by the devb-* drivers when mounting an ISO-9660 filesystem.

Although Ext2 is the main filesystem for Linux systems, we don't recommend that you use fs-ext2.so as a replacement for the QNX 4 filesystem. Currently, we don't support booting from Ext2 partitions. Also, the Ext2 filesystem relies heavily on its filesystem checker to maintain integrity; this and other support utilities (e.g. mke2fs) are not currently available for QNX 6.

For more information

See fs-ext2.so in the Utilities Reference.