Scribd
Upload
71 views

Virtual File System - Linux

A virtual file system (VFS) provides a unified interface for accessing different file systems transparently. The VFS specifies an interface between the kernel and concrete file systems. It represents core file system objects like superblocks, inodes, directories and files as objects with defined operations. This allows new file system types to be added by implementing the object operations for that type. The Linux VFS implements this concept, separating actual file system code from the rest of the kernel through standardized file system objects and interfaces.

Uploaded by

archiseth_516303960
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
71 views

Virtual File System - Linux

A virtual file system (VFS) provides a unified interface for accessing different file systems transparently. The VFS specifies an interface between the kernel and concrete file systems. It represents core file system objects like superblocks, inodes, directories and files as objects with defined operations. This allows new file system types to be added by implementing the object operations for that type. The Linux VFS implements this concept, separating actual file system code from the rest of the kernel through standardized file system objects and interfaces.

Uploaded by

archiseth_516303960
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Virtual File System

A virtual file system (VFS) or virtual filesystem switch is an abstraction layer


on top of a more concrete file system. The purpose of a VFS is to allow client
applications to access different types of concrete file systems in a uniform way. A
VFS can, for example, be used to access local and network storage devices
transparently without the client application noticing the difference. It can be used to
bridge the differences in Windows, classic Mac OS/macOS and Unix filesystems, so
that applications can access files on local file systems of those types without having
to know what type of file system they are accessing.
A VFS specifies an interface (or a "contract") between the kernel and a concrete file
system. Therefore, it is easy to add support for new file system types to the kernel
simply by fulfilling the contract. The terms of the contract might change
incompatibly from release to release, which would require that concrete file system
support be recompiled, and possibly modified before recompilation, to allow it to
work with a new release of the operating system; or the supplier of the operating
system might make only backward-compatible changes to the contract, so that
concrete file system support built for a given release of the operating system would
work with future versions of the operating system.

The main data item in any Unix-like system is the ``file'', and an unique pathname
identifies each file within a running system. Every file appears like any other file in
the way is is accessed and modified: the same system calls and the same user
commands apply to every file. This applies independently of both the physical
medium that holds information and the way information is laid out on the medium.
Abstraction from the physical storage of information is accomplished by dispatching
data transfer to different device drivers; abstraction from the information layout is
obtained in Linux through the VFS implementation.

The Unix way


Linux looks at its file-system in the way Unix does: it adopts the concepts of super-
block, inode, directory and file in the way Unix uses them. The tree of files that can
be accessed at any time is determined by how the different parts are assembled
together, each part being a partition of the hard driver or another physical storage
device that is ``mounted'' to the system.
While the reader is assumed to be confident with the idea of mounting a file-
system, I'd better detail the concepts of super-block, inode, directory and file.
 The super-block owes its name to its historical heritage, from when the first
data block of a disk or partition was used to hold meta-information about the
partition itself. The super-block is now detached from the concept of data
block, but still is the data structure that holds information about each
mounted file-system. The actual data structure in Linux is called struct
super_block and hosts various housekeeping information, like mount flags,
mount time and device blocksize. The 2.0 kernel keeps a static array of such
structures to handle up to 64 mounted file-systems.
 An inode is associated to each file. Such an ``index node'' encloses all the
information about a named file except its name and its actual data. The
owner, group, permissions and access times for a file are stored in its inode,
as well as the size of the data it holds, the number of links and other
information. The idea of detaching file information from filename and data is
what allows to implement hard-links -- and to use the `dot' and `dot-dot'
notations for directories without any need to treat them specially. An inode is
described in the kernel by a struct inode.
 The directory is a file that associates inodes to filenames. The kernel has no
special data strcture to represent a directory, which is treated like a normal
file in most situations. Functions specific to each filesystem-type are used to
read and modify the contents of a directory independently of the actual
layout of its data.
 The file itself is something that is associated to an inode. Usually files are
data areas, but they can also be directories, devices, FIFO's or sockets. An
``open file'' is described in the Linux kernel by a struct file item; the
structure encloses a pointer to the inode representing the file. file structures
are created by system calls like open, pipe and socket, and are shared by
father and child across fork.

Object Orientedness
While the previous list describes the theoretical organization of information, an
operating system must be able to deal with different ways to layout information on
disk. While it is theoretically possible to look for an optimum layout of information
on disks and use it for every disk partition, most computer users need to access all
of their hard drives without reformatting, mount NFS volumes across the network,
and sometimes even access those funny CDROM's and floppy disks whose filenames
can't exceed 8+3 characters.
The problem of handling different data formats in a transparent way has been
addresses by making super-blocks, inodes and files into ``objects'': an object
declares a set of operations that must be used to deal with it. The kernel won't be
stuck into big switch statements to be able to access the different physical layouts
of data, and new ``filesystem types'' can be added and removed at run time.
All the VFS idea, therefore, is implemented around sets of operations to act on the
objects. Each object includes a structure declaring its own operations, and most
operations receive a pointer to the ``self'' object as first argument, thus allowing
modification of the object itself.
In practice, a super-block structure, encloses a field ``struct super_operations
*s_op'', an inode encloses ``struct inode_operations *i_op'' and a file encloses
``struct file_operations *f_op''.
All the data handling and buffering that is performed by the Linux kernel is
independent of the actual format of the stored data: every communication with the
storage medium passes through one of the operations structures. The ``file-system
type'', then, is the software module that is in charge of mapping the operations to
the actual storage mechanism -- either a block device, a network connection (NFS)
or virtually any other mean to store/retrieve data. These software modules
implementing filesystem types can either be linked to the kernel being booted or
actually compiled in the form of loadable modules.
The current implementation of Linux allows to use loadable modules for all the
filesystem types but the root filesystem (the root filesystem must be mounted
before loading a module from it). Actually, the initrd machinery allows to load a
module before mounting the root filesystem, but this technique is usually only
exploited in installation floppies.
In this article I use the phrase ``filesystem module'' to refer independently to a
loadable module or a filesystem decoder linked to the kernel.
Linux Virtual File System
The Linux kernel implements the concept of Virtual File System (VFS, originally
Virtual Filesystem Switch), so that it is (to a large degree) possible to separate
actual "low-level" filesystem code from the rest of the kernel. The API of a
filesystem is described below.
This API was designed with things closely related to the ext2 filesystem in mind. For
very different filesystems, like NFS, there are all kinds of problems.
Four main objects: superblock, dentries, inodes, files
The kernel keeps track of files using in-core inodes ("index nodes"), usually derived
by the low-level filesystem from on-disk inodes.
A file may have several names, and there is a layer of  dentries ("directory entries")
that represent pathnames, speeding up the lookup operation.
Several processes may have the same file open for reading or writing,
and file structures contain the required information such as the current file position.
Access to a filesystem starts by mounting it. This operation takes a filesystem type
(like ext2, vfat, iso9660, nfs) and a device and produces the in-core superblock that
contains the information required for operations on the filesystem; a third
ingredient, the mount point, specifies what pathname refers to the root of the
filesystem.

Auxiliary objects

We have filesystem types, used to connect the name of the filesystem to the


routines for setting it up (at mount time) or tearing it down (at umount time).
A struct vfsmount represents a subtree in the big file hierarchy - basically a pair
(device, mountpoint).
A struct nameidata represents the result of a lookup.
A struct address_space gives the mapping between the blocks in a file and blocks
on disk. It is needed for I/O.

You might also like