Virtual File System in Linux:
1. Goals:
Linux is designed to support many different physical devices. Even for one specific type of device, such as hard drives, there are many interface differences between different hardware vendors. Linux supports a number of logical file systems. It can inter-operate easily with other operating systems. The Linux file system supports the following goals:
Multiple hardware devices: provide access to many different hardware devices.
Multiple logical file systems: support many different logical file systems.
Multiple executable formats: support several different executable file formats (like a out, ELF, Java).
Homogeneity: present a common interface to all of the logical file systems and all hardware devices.
Performance: provide high-speed access to files.
Safety: do not lose or corrupt data.
Security: restrict user access to access files; restrict user total file size with quotas.
2. External Interface:
The file system provides two levels of interface: a system-call interface that is available to user processes, and an internal interface that is used by other kernel subsystems. The system-call interface deals with files and directories. Operations on files include the usual open/close/read/write/seek/tell that are provided by POSIX compliant systems; different types of operations on directories include readdir/creat/unlink/chmod/stat as usual for POSIX systems.
The interface that the file subsystem supports for other kernel subsystems is much richer. The file subsystem exposes data structures and implementation function for direct manipulation by other kernel subsystems. In particular, two interfaces are exposed to the rest of the kernel --- inodes and files. Other implementation details of the file subsystem are also used by other kernel subsystems, but this use is less common.
Inode Interface:
create(): create a file in a directory
lookup(): find a file by name within a directory
link() / symlink() / unlink() / readlink() / follow_link(): manage file system links
mkdir() / rmdir(): create or remove sub-directories
mknod(): create a directory, special file, or regular file
readpage() / writepage(): read or write a page of physical memory to a backing store
truncate(): set the length of a file to zero
permission(): check to see if a user process has permission to execute an operation
smap(): map a logical file block to a physical device sector
bmap(): map a logical file block to a physical device block
rename(): rename a file or directory
In addition to the methods you can call with an inode, the namei() function is provided to allow other kernel subsystems to find the inode associated with a file or directory.
File Interface:
open() / release(): open or close the file
read() / write(): read or write to the file
select(): wait until the file is in a particular state (readable or writeable)
Iseek(): if supported, move to a particular offset in the file
mmap(): map a region of the file into the virtual memory of a user process
fsync() / fasync(): synchronize any memory buffers with the physical device
readdir: read the files that are pointed to by a directory file
ioctl: set file attributes
check_media_change: check to see if a removable media has been removed (such as a floppy)
revalidate: verify that all cached information is valid
3. Subsystem Description:
The file subsystem needs to support many different logical file systems and many different hardware devices. It does this by having two conceptual layers that are easily extended. The device driver layer represents all physical devices with a common interface. The virtual file system layer (VFS) represents all logical file systems with a common interface. The conceptual architecture of Linux kernel shows how this decomposition is conceptually arranged.
Device Drivers:
The device driver layer is responsible for presenting a common interface to all physical devices. Linux kernel has three types of device driver: character, block and network. The two types relevant to file subsystem are character and block devices. Character devices must be accessed sequentially such as tape drives, modems, and mice. Block devices can be accessed in any order but can only be read and written to in multiples of the block size.
Each device can be accessed as though it was a file in file system. This file is referred to as a device special file. Most of kernel deals with devices via file interface, it is easy to add a new device driver by implementing hardware-specific code to support this file interface.
Linux kernel uses a buffer cache to improve performance when accessing block devices. All access to block devices occurs through a buffer cache subsystem. The buffer cache greatly increases system performance by minimizing reads and writes to hardware devices. Each hardware device has a request queue; when the buffer cache cannot fulfill a request from in-memory buffers, it adds a request to the device's request queue and sleeps until this request has been satisfied. The buffer cache uses a separate kernel thread, kflushd, to write buffer pages out to the devices and remove them from the cache.
When a device driver needs to satisfy a request, it begins by initiating the operation with hardware device manipulating the device's control and status registers (CSR's). There are three general mechanisms for moving data from the main computer to peripheral device: polling, direct memory access (DMA) and interrupts.
When a hardware device wants to report a change in condition (mouse button pushed, key pressed) or to report the completion of an operation, it sends an interrupt to the CPU. If interrupts are enabled, CPU stops executing current instruction and begins executing Linux kernel's interrupt handling code. The kernel finds appropriate interrupt handler to invoke. While an interrupt is being handled, CPU executes in a special context; other interrupts may be delayed until the interrupt is handled. Because of this restriction interrupt handlers need to be quite efficient so that other interrupts are not lost. Sometimes an interrupt handler cannot complete all required work within the time constraints. In this case, the interrupt handler schedules the work in a bottom-half handler. A bottom-half handler is code that is executed by scheduler the next time a system call is completed.
Logical File Systems:
It is possible to access physical devices through device special file. It is more common to access block devices through a logical file system. A logical file system can be mounted at a mount point in virtual file system. It means that the associated block device contains files and structure information that allow logical file system to access the device. At any one time, a physical device can only support one logical file system. However, the device can be reformatted to support a different logical file system.
When a file system is mounted as a subdirectory, all directories and files available on the device are made visible as subdirectories of mount point. Users of virtual file system do not need to be aware what logical file system is implementing which parts of directory tree etc. This abstraction provides a great deal of flexibility in the choice of physical devices and logical file systems. It is one of the essential factors in success of Linux operating system.
Linux uses the concept of inodes to support virtual file system. It uses an inode to represent a file on a block device. The inode is virtual in the sense that it contains operations that are implemented differently depending on logical system and physical system. The inode interface. makes all files appear the same to other Linux subsystems. It is used as a storage location for all of the information related to an open file on disk. It stores associated buffers, total length of file in blocks and the mapping between file offsets and device blocks.
Modules:
Most of the functionality of virtual file system is available in the form of dynamically loaded modules. This dynamic configuration allows Linux users to compile a kernel that is as small as possible, while still allowing it to load required device driver and file system
modules if necessary during a single session. For example, a Linux system might optionally have a printer attached to its parallel port. If printer driver were always linked in to kernel, then memory would be wasted when the printer isn't available. By making the printer driver be a loadable module, Linux allows the user to load the driver if the hardware is available.
4. Data Structures:
The following data structures are architecturally relevant to the file subsystem:
super_block: Each logical file system has an associated superblock used to represent it to the rest of Linux kernel. It contains information about the entire mounted file system.
inode: An inode is an in-memory data structure that represents all of the information that the kernel needs to know about a file on disk. It stores all of the information that the kernel needs to associate with a single file. Accounting, buffering, and memory mapping information are all stored in the inode.
file: The file structure represents a file that is opened by a particular process. All open files are stored in a doubly-linked list. The file-descriptor used in POSIX style routines (open, read, write) is the index of a particular open file in this linked list.
5. Subsystem Structure:
The file system depends on all other kernel subsystems and all other kernel subsystems depend on the file subsystem. In particular, the network subsystem depends on the file system because network sockets are presented to user processes as file descriptors. The memory manager depends on file system to support swapping. The IPC subsystem depends on file system to implement pipes and FIFO's. The process scheduler depends on file system to load modules.
The file system uses the network interface to support NFS. It uses memory manager to implement buffer cache and for a ramdisk device. It uses IPC subsystem to help support modules and it uses process scheduler to put user processes to sleep while hardware requests are completed.
