The structure of VFS makes it particularly convenient to add different sorts of file systems. Since each file system provides its own implementation of the VFS calls, each file system is in complete control of its semantics.
A local file system is associated with a device driver,
a body of code that provides the operating system with
functions to call to control a physical device. Device drivers
can be found in the /dev directory on Unix systems.
A file system type maps the file system operations needed
by VFS into actual device driver calls.
A similar system is required for remote file systems, but rather than using a driver for some local hardware, the file system operations must be translated into network operations. NFS (network file system) from Sun Microsystems was an early standard based on remote procedure calls that is still the standard for Unix-like operating systems.
There are two separate tasks that are normally done locally that must be supported over the network for a network file system to work: mounting and performing the actual I/O calls. Both are done via RPC.
Mounting
Mounting a file system is the act of associating a specific file system implementation with a particular point in the directory hierarchy. For local file systems, the implementation is contained in a device driver. All file systems have to be mounted before they can be used, and one of the first things that a Unix system does when the kernel starts running is to mount some device on/. On
cs the device mounted on / is /dev/mapper/vg0-lvroot.
To see all the currently mounted file systems, you can type the
mount command. You can see that the file system
type for / is ext3. The file system
type tells the kernel how to translate the normal I/O calls to
operations from the the actual implementation.
The basic command equivalent to what puma does at
boot is:
mount /dev/mapper/vg0-lvroot /
If you are root, you can mount a file system at
an existing directory in the directory tree. Once mounted, any
file system activity going through the inode of the mount
point is redirected through the mounted file system. The
old directory is not deleted, it is merely inaccessible until
the file system is unmounted (via the umount
command). Normally you can't unmount a file system while
someone is using any of its files, but there is a way to force
the issue (e.g., for system reboot).
The mount protocol specification from Sun specifies 7 procedures, the most import of which perform the mount and unmount requests.
NFS File Systems
There are a variety of file system types already known to the kernel. The Sun Network File System (NFS) is one that doesn't map VFS operations to calls into a local device driver: rather it converts VFS call into network operations (RPCs) that get carried out on a (potentially) separate machine.Mounting a remote file system under NFS is fairly
straightforward. The main thing you have to do is provide a
remote machine name and a directory on that machine (rather than
a local device driver). Operations that go through the mount
point will then be resolved relative to the given directory on
the specified remote machine.
The following command asks the kernel to use NFS to mount the
file system named /home on puma on the
local directory /tmp/bar.
mount -t nfs puma:/home /tmp/bar
File Servers — Possessed by daemons
To understand what happens on a mount request and subsequent file system operations, we have to understand a little more about what happens on the server.A server runs several daemons in support of remote
file system service. Normally, in Unix systems, a process is
associated with the terminal (or console) from which is was
executed. A daemon is a process that is intended to run for an
extended period of time, perhaps as long as the machine is up.
Daemons therefore run in the background disconnected from any
terminal. (There is a system call, setpgid(), a
process can make to disconnect from its controlling terminal and
run in daemon mode.)
The mount daemon (mountd) is a program that
listens on some port for mount requests. After receiving
a request, the mount daemon determines whether the client is
permitted to mount the directory in question, and, if so, it
responds with something called the root file handle for
the directory. A file handle is a dynamic name that can be
submitted as part of future file system requests: it serves the
same function as an inode number on a single file system.
Future requests are processed by the NFS daemon
(nfsd), which processes most requests relative to a
specific file handle. In essence, the NFS daemon maps network
file handles to objects and requests (such as
readdir()) to VFS operations in the underlying file
system.
Here is the Sun specification for the NFS version 2 RPCs.
Modified: 17 April 2007