Virtual File Systems

Virtual file systems are memory-based file systems
that provide access to special kernel information and facilities. Most virtual
file systems do not use file system disk space. However, the CacheFS file
system uses a file system on the disk to contain the cache. Also, some virtual
file systems, such as the temporary file system (TMPFS), use the swap space
on a disk.

CacheFS File System

The CacheFS file system can be used to improve
the performance of remote file systems or slow devices such as CD-ROM drives.
When a file system is cached, the data that is read from the remote file system
or CD-ROM is stored in a cache on the local system.

If you want to improve the performance and scalability of an NFS or
CD-ROM file system, you should use the CacheFS file system. The CacheFS software
is a general purpose caching mechanism for file systems that improves NFS
server performance and scalability by reducing server and network load.

Designed as a layered file system, the CacheFS software provides the
ability to cache one file system on another. In an NFS environment, CacheFS
software increases the client per server ratio, reduces server and network
loads, and improves performance for clients on slow links, such as Point-to-Point
Protocol (PPP). You can also combine a CacheFS file system with the autofs
service to help boost performance and scalability.

NFS Version 4 and CacheFS Compatibility Issues

If both the CacheFS client and the CacheFS server are running NFS version
4, files are no longer cached in a front file system. All file access is provided
by the back file system. Also, since no files are being cached in the front
file system, CacheFS-specific mount options, which are meant to affect the
front file system, are ignored. CacheFS-specific mount options do not apply
to the back file system.

Note –

The first time you configure your system for NFS version 4, a
warning appears on the console to indicate that caching is no longer performed.

If you want to implement your CacheFS mounts as in previous Solaris
releases, then specify NFS version 3 in your CacheFS mount commands.
For example:

Temporary File System

The temporary file system (TMPFS) uses local memory for file system
reads and writes. Typically, using memory for file system reads and writes
is much faster than using a UFS file system. Using TMPFS can improve system
performance by saving the cost of reading and writing temporary files to a
local disk or across the network. For example, temporary files are created
when you compile a program. The OS generates a much disk activity or network
activity while manipulating these files. Using TMPFS to hold these temporary
files can significantly speed up their creation, manipulation, and deletion.

Files in TMPFS file systems are not permanent. These files are deleted
when the file system is unmounted and when the system is shut down or rebooted.

TMPFS is the default
file system type for the /tmp directory in the Oracle Solaris OS.
You can copy or move files into or out of the /tmp directory,
just as you would in a UFS file system.

The TMPFS file system uses swap space as a temporary backing store.
If a system with a TMPFS file system does not have adequate swap space, two
problems can occur:

The TMPFS file system can run out of space, just as regular
file systems do.

The Loopback File System

The loopback file system (LOFS) lets you create a new virtual file system
so that you can access files by using an alternative path name. For example,
you can create a loopback mount of the root (/) directory
on /tmp/newroot. This loopback mounts make the entire
file system hierarchy appear as if it is duplicated under /tmp/newroot,
including any file systems mounted from NFS servers. All files will be accessible
either with a path name starting from root (/), or with
a path name that starts from /tmp/newroot.

Process File System

The process file system (PROCFS) resides in memory and contains
a list of active processes, by process number, in the /proc directory.
Information in the /proc directory is used by commands
such as ps. Debuggers and other development tools can also
access the address space of the processes by using file system calls.

Caution –

Do not delete files in the /proc directory. The deletion of processes from the /proc directory
does not kill them. /proc files do not use disk space,
so there is no reason to delete files from this directory.

The /proc directory does not require administration.

Additional Virtual File Systems

These additional types of virtual file systems are listed for your information.
They do not require administration.

Virtual File System

Description

CTFS

CTFS (the contract file system) is the interface for creating, controlling,
and observing contracts. A contract enhances the relationship between a process
and the system resources it depends on by providing richer error reporting
and (optionally) a means of delaying the removal of a resource.

The service management facility (SMF) uses process contracts (a type
of contract) to track the processes which compose a service, so that a failure
in a part of a multi-process service can be identified as a failure of that
service.

FIFOFS (first-in first-out)

Named pipe files that give processes common access to data

FDFS (file descriptors)

Provides explicit names for opening files by using file descriptors

MNTFS

Provides read-only access to the table of mounted file systems for the
local system

NAMEFS

Used mostly by STREAMS for dynamic mounts of file descriptors on top
of files

OBJFS

The OBJFS (object) file system describes the state of all modules currently
loaded by the kernel. This file system is used by debuggers to access information
about kernel symbols without having to access the kernel directly.

SHAREFS

Provides read-only access to the table of shared file systems for the
local system

SPECFS (special)

Provides access to character special devices and block devices

SWAPFS

Used by the kernel for swapping

libc_hwcap

The mount output on an x86 system might include a loopback mount of
a libc_hwcap library, a hardware-optimized implementation
of libc. This libc implementation
is intended to optimize the performance of 32-bit applications.

This loopback mount requires no administration and consumes no disk
space.