Other file systems

The initial push for redesigning the file system handling code was the introduction of NFS, or the Network File System. Suddenly, files could no longer be accessed directly, since they were not necessarily local and they were not necessarily UNIX files! There is nothing to prevent a completely different system with a unique OS from offering its files for access over the network. This flexibility meant that file system type information or file information had to be divided: into the parts that were general and could be used by any machine; and into the parts that were entirely specific to that file or file system type, on that system, and would have to be handled by the local system itself.

Once the new design was implemented, the set of file system types that could be handled locally was also increased, even to the point of creating "pseudo" file systems that actually didn't have a file system, files, or real devices. Solaris 2 has a greatly expanded repertoire when it comes to handling file system types.

Some of the more common file system or disk formats you will find:

• HSFS ” High Sierra (ISO 9660) CD-ROM disks.

• PCFS ” PC format (DOS) diskettes.

• lofs ” "loop-back" file system. A currently mounted file system or directory can be mounted onto another point in the file system hierarchy, creating essentially two paths to the contents.

• procfs ” process file system. In Solaris 2, this file system, normally mounted on /proc , contains one "file" entry for each process on the system. Opening one of these files can provide access to information about the process. This information is used by such programs as ps , which requires some data from the kernel about the state, size , and time consumption of the given process. procfs is a replacement for the kvm libraries, which allowed programs to actually open up kernel data space and read the internal tables directly.

• specfs ” Handles special files (devices) directly.

• tmpfs ” Uses swap space to hold a temporary variable- sized file system to be used for /tmp .

• and, of course, NFS (the original) ” Mounts and accesses file systems that are controlled by other machines elsewhere on the network.

Some examples of supporting routines for these other file system types are:

• hsfs_getattr() ” Get information about a file on a CD.

• nfstsize() ” Check the network interfaces and return the preferred NFS transfer size.

• tmp_mount() ” Create and mount a file system in swap.

• spec_badop() ” Prove the "error" routine for many of the VFS functions applied to devices. For example, how can you issue a statvfs system call on a terminal device when there is no file system there?

As you can see, every file system type provides the same general functions to access the data that resides there. Most system calls are processed at various levels: the general level to validate the parameters, then at the vnode level to do file-oriented things, and then at the file or file system-specific level to take care of accessing real data if needed. These are usually well named functions, and can be easily recognized as referring to a specific type of file system.