Understanding File Systems

File systems are not new concepts at this point in the book. From the preceding two chapters, you should remember that file systems can be looked at in a few different ways. One way is that a file system is a logical unit of storage, such as the entire file tree, beginning with the root directory. Another way is that a file system defines the specific methods used to store and retrieve data from hard disks. Both are perfectly acceptable ways to think of file systems. Just understand that when someone mentions a file system, they might be thinking of it in a different light than you.

Solaris 9 supports several types of file systems. Again, how you define the multiple types depends on which way you look at file systems. For ease of categorization, though, this chapter classifies file systems into three categories: disk based (or local), network based (or distributed), and pseudo (or virtual). Three categories with two names each can understandably be a bit confusing. And to add to the potential confusion, a few file systems, such as Universal Disk Format (UDF), can be classified as either a local file system or a virtual file system.

There are some new file system features in Solaris 9. They include:

The use of extended file system attributes These enable developers and administrators to create certain types of attributes and associate them to a file. For example, if a developer wanted a certain type of file to be represented with a particular icon within the Common Desktop Environment (CDE), she could include the icon type as an extended file attribute.

The ability to create UNIX File System (UFS) snapshots Traditionally, to back up a file system, you have to unmount the file system, making it temporarily inaccessible. In Solaris 9, you can take a UFS snapshot of a mounted file system for backup purposes. Snapshots are discussed in more detail in Chapter 9, "System Backups and Restores."

UFS I/O concurrency In previous versions of Solaris, if a file was being written to, it was temporarily locked from read operations. Solaris 9 allows for concurrent read and write access to UFS files because of an improved data buffering method. This is especially helpful for database files.

Improved performance from mkfs The mkfs (make file system) command is used to create file systems. The version of mkfs included with Solaris 9 can be up to 10 times faster than previous versions.

New labelit options For UDF file systems, labelit now enables you to create labels to identify the person creating the file system, the organization responsible for file system creation, and contact information for the responsible parties.

As discussed in Chapter 5, "Files, Directories, and Security," the file system structure of Solaris is hierarchical. The base of the file system tree is the root, represented by a slash (/). Other directories and file systems can be represented by their absolute path from the root, such as /export/home/userx. There are nine default Solaris file systems to consider, as shown in Table 7.1.

Table 7.1: Default Solaris 9 File Systems

File System	Type	Purpose
root (/)	UFS	The top of the hierarchical file system. Also contains files and directories critical for system operation.
/etc/mnttab	MNTFS	A file system dedicated to maintaining the table of mounted file systems. This file system is read-only.
/export/home or /home	NFS, UFS	For user home directories.
/opt	UFS	Optional file system for third-party software. If local, it's UFS. If remote, it's NFS.
/proc	PROCFS	The active processes on the system.
/tmp	TMPFS	Temporary files. The files in this file system are removed when the system is rebooted or when /tmp is unmounted.
/usr	UFS	Files and directories that are to be shared with other users. User commands and man pages are stored in /usr.
/var	UFS	Variable data that changes over time. Examples are log files and some backup files.
/var/run	TMPFS	A file system storing temporary files that are not needed after the system is booted.

When you look at this table, you might think, "Wait a minute! This looks a lot like Table 5.3, which listed the default directories. What's the deal?" Good question.

This is when the differentiations between file systems and directories can become confusing. For example, is /usr a file system or is it a directory? The answer can be an ambiguous "yes."

Perhaps a better question to ponder is, "Does it really matter whether it's a file system or a directory?" It depends on what you're doing. If you're simply navigating the directory structure and want to get to your home directory in /export/home, it really doesn't matter. You can simply use the cd command to get to your desired working directory. However, if you're trying to create a hard link, now it does matter. As you might recall, hard links can be created only in the same file system as the original file.

Suppose that you create a new slice, slice 4, create a file system called /docs on it, and mount it. What would your users see? They would see a directory called /docs. The vast majority of your users won't know whether it's a directory or file system, and they likely won't care. All they care about is that they can access the files they need in /docs. As the administrator, you might need to differentiate because of disk space allocation and file system management (such as backups).

One last point to consider is how the file system or directory was created. If you used mkdir, it's obviously a directory. However, if you used mkfs or newfs, it's a file system. Generally speaking, though, file systems look like directories, and for navigational purposes, they act like directories. A directory, however, isn't necessarily its own file system.

File System Structure

Creating a file system on a hard disk divides the disk slice into cylinder groups. The cylinder groups are then subdivided into blocks to provide an organizational structure within the slice. Each block has a unique address within the slice. The four types of blocks are boot block, superblock, inode, and data (or storage) block.

The boot block is present only in slice 0, as this is the boot slice. In all other slices, the area normally reserved for the boot block is left blank. The boot block is very small, only 8KB, and contains enough information to begin the system's boot process.

The superblock contains critical file system information. The information stored by the superblock includes the size of the file system, the disk label (Volume Table of Contents), cylinder group size, number of data blocks present, the summary data block, file system state (state flag), and the pathname of the last mount point. There's no sense in memorizing this list; just know that the superblock is critical. In fact, if the superblock were lost, the file system would be inaccessible.

The superblock is located at the beginning of each slice, and is replicated within each cylinder group for redundancy. If the slice spans multiple hard disk platters, the spacing of superblock replicas is calculated to provide at least one superblock on each disk platter. Replicas can be used to replace the original superblock if the original becomes corrupt or lost.

An inode is a 128-byte block that contains all the information about a file except for the file's name. Filenames are stored in directories. The information stored in an inode includes the file's type (directory, regular, socket, and so on), the file's mode (basic permission set), the number of hard links to the file, the User ID and Group ID of the file's owners, the size of the file, the last modification date and time, and the date and time that the file was created. The inode also points to the blocks that contain the actual data within the file. Each file needs one inode.

Note 

By restricting the number of inodes within a slice, you can effectively restrict the number of possible files stored in the slice.

Data blocks contain the data of the file. By default, the blocks are allocated in 8KB chunks, with a certain portion reserved as 1KB fragment blocks. Fragment blocks are used to increase disk efficiency when a file does not need a full 8KB block.

Disk-Based File Systems

As their name implies, disk-based file systems are created on some sort of physical media. Generally speaking, disk-based file systems are accessed locally. Examples include hard disks, CD-ROMs, and floppy disks. Solaris supports four types of disk-based file systems:

• UNIX File System (UFS) for hard disks

• High Sierra File System (HSFS) for CD-ROMs

• Personal Computer File System (PCFS) for floppy disks

• Universal Disk Format (UDF) for DVD-ROMs

UFS is the default file system for hard disks in Solaris. Also, know that the preceding pairings are not always absolute. For example, although UFS is typically associated with hard disks, it can also be used on CD-ROMs and floppy disks. Be assured, however, that if someone mentions HSFS, they are discussing CD-ROMs, and likewise with UDF and DVD-ROMs.

If you plan on creating UFS file systems on CD-ROMs or floppy disks, you might run into compatibility problems. Generally speaking, it's best to use HSFS for CD-ROMs, because this format is industry-standard. In other words, an HSFS-based CD-ROM will work as well in a Solaris computer as it will in a Windows-based PC. The same holds true for floppy disks. Although you can use UFS, it's best to stick with PCFS.

Distributed File Systems

A distributed file system is also known as a network-based file system. This is because, as you might expect, they are accessed across a network. The network-based file system supported in Solaris 9 is the Network File System (NFS). NFS volumes typically reside on a server and are accessed by clients across the network.

Note 

Sharing resources is perhaps the most important reason people create networks in the first place. Understandably then, NFS is a critical topic. Because of its importance, and because it's tested on the second exam, NFS is covered extensively in Chapter 11, "Virtual File Systems and NFS."

For now, though, here's a brief introduction to NFS. The idea is that an administrator can share resources from one centralized location: the server. This saves the hassle of locating commonly used files on every client machine. Clients then attach to the server to access resources. To do this, the client computer needs to create a mount point, which points to the location of the resources on the server. A mount point looks just like any other directory on the local machine. Therefore, the mounted resources and local resources appear identical to users. Of course, as administrators, we know differently. But anything we can do to keep our users' computing lives as easy as possible is a good thing.

Remote NFS resources can be mapped automatically when the client computer boots through a process known as automounting, or AutoFS. AutoFS will automatically mount the remote resource whenever the resource is accessed and keep the connection to the resource alive while the user is in the directory or using files. After a certain period of inactivity, AutoFS will unmount the remote resource. AutoFS is covered in more detail along with NFS in Chapter 11.

Pseudo File Systems

Pseudo file systems, also known as virtual file systems, are named this because most of them do not use disk space. Rather, a pseudo file system uses system memory to complete their tasks. The notable exceptions are CacheFS and TMPFS, which do use hard disk space. There are ten common virtual file systems, six of which require no administrative attention. Some of the more important virtual file systems are as follows:

Cache File System (CacheFS) CacheFS is designed to improve performance of remote file systems and of slow disk devices. When CacheFS is activated, it caches information located on remote drives or CD-ROMs into local memory, speeding up access to this data. CacheFS is most useful when used with NFS or with CD-ROM drives.

Loopback File System (LOFS) You can use LOFS to create a virtual file system within your current file system. For example, you could use LOFS to create a replica of the root in a directory called /docs/roothd. Because it's a replica, the /docs/roothd directory would look just like the real root (/), including all files and subdirectories.

Mount File System (MNTFS) The MNTFS file system is a read-only file system that tracks currently mounted file systems within the computer. MNTFS requires no administrative overhead.

Process File System (PROCFS) PROCFS keeps a list of all active processes running on the system. This list is stored in memory and is referenced by the /proc directory.

Swap File System (SWAPFS) If your computer runs low on physical memory, the kernel can use swap space (located in a SWAPFS file system) as virtual memory. The positive side to this is that when you run low on memory, your system can compensate. The negative is that disk access is significantly slower than physical memory access. If you are using swapping too much, you need to increase the amount of physical memory in your computer. Disk swapping is handled automatically and requires no administrative intervention. SWAPFS is covered extensively in Chapter 11.

Temporary File System (TMPFS) TMPFS improves system performance by using local memory to store disk reads and writes. Memory access is significantly faster than hard disk access. Although files in TMPFS are lost when the system is powered down or TMPFS is unmounted, you can manipulate those files (located in the /tmp directory) just as you would other system files.

The other virtual file systems include First-In First-Out (FIFOFS), File Descriptors (FDFS), Name (NAMEFS), and Special (SPECFS). None of these file systems require interaction from the administrator to function properly. Also, none of these file systems are currently listed as test objectives.