Chapter 8: The Virtual Filesystem
(determined by the network filesystem). The remote computer is then responsible for storing
the transmitted data and for informing the sender that the data have arrived.
Nevertheless, the kernel needs information on the size of files, their position within the
directory hierarchy, and other important characteristics, even when it is working with net-
work filesystems. It must also provide functions to enable user processes to perform typical
file-related operations such as open, read, or delete. As a result of the VFS layer, userspace
processes see no difference between a local filesystem and a filesystem available only via a
network.8.2 The Common File Model
The VFS not only provides methods and abstractions for filesystems, but also supports a uniform view
of the objects (orfiles) in the filesystem. Even though the meaning of the termfilemay appear to be clear,
there are many small, often subtle differences in detail owing to the underlying implementations of the
individual filesystems. Not all support the same functions, and some operations (which are indispensable
for ‘‘normal‘‘ files) make no sense when applied to certain objects —named pipes, for instance — which
are also integrated into VFS.Not every filesystem supports all abstraction types in VFS. Device files cannot be stored in filesystems
originating from other systems (i.e., FAT) because the latter do not cater to objects of this kind.Defining a minimum common model that supports only those functions implemented byallfilesystems
in the kernel is not practical because many essential features would be lost or would only be accessible via
filesystem-specific paths. This would negate the benefits of a virtual abstraction layer. The VFS answer is
quite the opposite — a structure model consisting ofall components that mirror a powerful filesystem.
However, this model exists only virtually and must be adapted to each filesystem using a variety of
objects with function pointers. All implementations must provide routines that can be adapted to the
structures defined by the VFS and can therefore act as a go-between between the two views.Naturally, the structure of the virtual filesystem is not a product of fantasy but is based on structures used
to describe classical filesystems. The VFS layer was alsoorganized to clearly resemble the Ext2 filesystem.
This makes life more difficult for filesystems based on totally different concepts (e.g., the Reiser filesystem
or XFS) but delivers speed gains when working with Ext2fs because practically no time is lost converting
between Ext2 and VFS structures.When working with files, the central objects differ in kernel space and userspace. For user programs, a
file is identified by afile descriptor. This is an integer number used as a parameter to identify the file in
all file-related operations. The file descriptor is assigned by the kernel when a file is opened and is valid
only within a process. Two different processes may therefore use the same file descriptor, but it does not
point to the same file in both cases. Shared use of files on the basis of the same descriptor number is not
possible.Theinodeis key to the kernel’s work with files. Each file (and each directory) has just one inode, which
contains metadata such as access rights, date of last change, and so on, and also pointers to the file data.
However, and this may appear to be slightly strange, the inode doesnotcontain one important item of
information — the filename. Usually, it is assumed that the name of a file is one of its major characteristics
and should therefore be included in the object (inode) used to manage it. I explain why this is not so in
the following section.