What Is a Virtual File System?

The Virtual File System (VFS) was created by Sun Microsystems when defining the Network File System (NFS). It is a distributed file system used in a network environment. It is an interface that allows different operating systems to be used with the operating system. The Virtual File System (VFS) is an interface layer between the physical file system and the service. It abstracts all the details of each file system in Linux, making different file systems appear to the Linux kernel and other processes running in the system. , Are all the same. Strictly speaking, VFS is not an actual file system. It only exists in memory and does not exist in any external storage space. VFS is established at system startup and dies when the system is shut down.

Chinese name: Virtual file system

Foreign name: Virtual File Systems
Field: Computer operating system

Introduction to Virtual File System

Virtual File Systems (VFS)

Linux is a new type of operating system developed in recent years. One of its most important features is that it supports multiple file systems, making it more flexible and coexisting with many other operating systems. Linux supports various file systems such as ext, ext2, xia, minix, umsdos, msdes, fat32, ntfs, proc, stub, ncp, hpfs, affs, and ufs. In order to achieve this, Linux uses a unified file interface for all file systems, and users implement operations on different file systems through file operation interfaces. For users, we don't care about the specific operation process of different file systems, but only operate a virtual file operation interface, which is the Linux Virtual File System (VFS). Visually speaking, the kernel of Linux is like a motherboard of a PC, VFS is the upper slot, and the specific file system is the 121 cards. Therefore, each file system does not interfere with each other, but only calls the corresponding program to achieve its function. In the Linux kernel file, VFS and specific file system programs are placed in Linux \ FS, each file system corresponds to a subdirectory, and there are some common VFS programs. In specific implementation, each file system has its own file operation data structure file_operations. Therefore, VFS, as a software layer in the ILinux kernel, is used to provide a file system interface for user-space programs. It also provides an abstraction function in the kernel to allow different file systems to coexist well. VFS makes it possible for Linux to mount and support many different types of file systems simultaneously. VFS has a common interface for various special file systems, such as superblocks, inodes, and file operation function entries. The details of the actual file system are uniformly indexed by the VFS's common interface, and they are transparent to the system core and user processes.

Linux Introduction to Linux Virtual File System

Virtual File System Virtual

The word "virtual" has two main meanings: ^[1]

1. In the same directory structure, several different file systems can be mounted. VFS hides their implementation details and provides a unified interface for users; ^[1]

2, the directory structure itself is not absolute, each process may see a different directory structure. The directory structure is described by "address space (namespace)", different processes may have different namespaces, different namespaces May have different directory structures (because they may have different file systems mounted). ^[1]

Inode Virtual File System Inode

Meaning: Inode, corresponding to a file stored on the device. ^[1]

Create: 1) When the superblock is loaded, the inodes that are the root are loaded together; 2) Innovate new inodes by calling mknod; 3) In the process of finding the file path, read from the device, and Initialization (Like super_block, part of the information in the inode structure is stored in the device, and part of it is initialized internally). ^[1]

Functions: i_op, an i-node function set, which mainly includes operations such as creating and deleting child inodes. F_op, a file function set, which mainly includes operations such as reading and writing to this inode. After the inode is created, 1) if it is a special file, According to the type of the corresponding file (including block device, character device, fifo, etc.) given a specific function set (not directly related to the device and file system type); 2) otherwise, the corresponding file system type will provide the corresponding Function set, and the directory and file function sets are likely to be different. ^[1]

Virtual file system operations on opened files

The user of VFS is a process (users always need to start the process to access the file system). The files pointer in the task_struct structure describing the process points to a files_struct structure, which describes the set of files that the process has opened. ^[1]

The files_struct structure maintains an array of pointers to the file structure corresponding to the opened file. The array index is used as a handle (usually called fd) for the user program to operate the opened file. The files_struct also maintains the used fd bitmap, When you need to open a file, assign it an unused fd. ^[1]

See references for details.

Virtual file system functions

The functions of VFS include: recording the types of file systems available; associating devices with corresponding file systems; handling some file-oriented common operations; when it comes to operations on file systems, VFS maps them to control files and directories And the inode-related physical file system.

When a process issues a file-oriented system call, the core will call the corresponding function in VFS. This function handles some operations that are not related to the physical structure, and redirects it to the corresponding function call in the real file system. It is used to deal with operations related to physical structure.

The encapsulation relationship between VFS and the actual file system is shown in the following figure:

VFS

MINIX FS

VFSinode cache

VFS directory cache

EXT FS

EXT2 FS

MSDS FS

Buffer storage

I / O device driver

Figure 4 Encapsulation relationship between VFS and actual file system

VFS source code is concentrated in the / usr / src / linux / fs directory, and its data structure is described in the file /usr/src/lunux/include/linux/fs.h.

Virtual file system superblock

VFS uses a similar approach to the EXT2 file system: superblocks and inodes describe the file system.

VFS superblocks are created during installation of various logical file systems and are automatically deleted when these file systems are unmounted. It only exists in memory. The VFS stores a linked list of file systems mounted in the system and the VFS superblocks corresponding to these file systems. After the system is started, all initialized file systems must be registered with the VFS. Each mounted file system is represented by a VFS superblock, which contains the following information:

Device: The device identifier of the block device where the file system is located. For example, the device identifier of the first IDE hard disk in the system is 0x301.

Inode pointers: This mounted inode pointer points to the first inode in the file system. The covered inode pointer points to the inode of this file system installation directory. The VFS superblock of the root file system does not contain a covered pointer.

Blocksize: The file system block size in bytes, such as 1024 bytes.

Superblock operations: A pointer to a set of superblock manipulation routines for this file system. These routines are used by VFS to read and write inodes and superblocks.

File System type: This is a pointer to the file_system_type structure of the mounted file system.

File System specific: Pointer to the information required by the file system.

Virtual file system related

The VFS Inode The VFS Inode

Like the EXT2 file system, each file, directory, etc. in the VFS is represented by and only one VFS inode. The information in each VFS inode is obtained from the underlying file system through file system related routines. VFS inodes exist only in core memory and are kept in the VFS inode cache as long as they are useful to the system. Each VFS inode contains the following domains:

device: The device identifier of the device containing this file or whatever this VFS inode represents.

inode number: The unique inode number in the file system. The combination of device and inode numbers is unique in the virtual file system.

mode: The same as in EXT2, which indicates the access rights of this VFS inode.

user ids: the identifier of the owner.

times: VFS inode creation, modification, and write time.

block size: The file block size in bytes, such as 1024 bytes.

inode operations: A pointer to the address of a set of routines. These routines are related to the file system and perform operations on this inode, such as truncating the file represented by this inode.

count: The number of system parts using this VFS inode. An inode with a count of 0 can be freely discarded or reused.

lock: Used to lock a VFS inode, such as when reading the file system.

dirty: indicates whether the VFS inode has been written. If so, the underlying file system needs to be updated.

Virtual file system registration file system

Users can register a file system with the kernel in two ways: one is to determine the type of file system that can be supported when compiling the kernel, and to register in the VFS through embedded function calls during system initialization; As a module, the module's load and unload feature is used to register the type with the registry or log out from the registry.

The file system type registration function is: int register filesystem (struct file_system_type * fs)

Each file system has an initialization routine, through which the file system is registered in the VFS, that is, fill in the file_system_type data structure. This structure contains the name of the file system and an address pointing to the corresponding VFS superblock read routine. The file_system_type structure of all registered file systems forms a registered linked list, as shown in the following figure:

file_system_type file_system_type file_system_type

* read_super ()

name

owner

kem_mnt

* read_super ()

name

owner

kem_mnt

* read_super ()

name

owner

kem_mnt

Figure 5

The data structure of file_system_type is defined in include / linux / fs.h as follows:

struct file_system_type {

const char * name;

// The type name of the file system, such as EXT2. These names appear in / proc / filesystems in Linux and must be unique.

int fs_flags;

// fs_flags can take many values. For example, the file system identifier FS_REQUIRES_DEV indicates that the file system can only be mounted on one block device; FS_SINGLE indicates that the file system can only have one superblock; FS_NOMOUNT indicates that the file system cannot be mounted on user space.

struct super_block * (* read_super) (struct super_block *, void *, int);

The function pointed by // read_super is used to read out the super block of the file system stored outside.

struct module * owner;

// If the program segment that implements the file system is dynamically loaded by the module, point to the module; if the program segment that implements the file system is generated during kernel compilation, owner = NULL.

struct vfsmount * kem_mnt;

// Use only for the file system identified as FS_SINGLE (For kernel mount)

struct file_system_type * next;

// Following pointer to file system type linked list.

};

Virtual file system mount file system

After the file system is registered, the file system is established in a certain format on the device, but at this time, files and nodes on the device are not yet accessible, and specific nodes or files cannot be accessed according to a certain path name. Only by installing it on a node in the file system can the files and nodes on the device be accessible. Therefore, the registration of the wej system only represents that the Linux system supports the application of this file system, and it must be installed to really use the file system.

To mount a file system, you must call the mount command to mount other subsystems on a free node that already exists in the file system. This command uses the system's mount () call: asmlinkage ling sys_mount (char * dev_name, char * dir_name, char * type, unsigned long flags, void * data)

Where dev_name is the path name of the disk partition of the file system to be mounted, such as / dev / hda5. The parameter dir_name is the directory name of the file system to be mounted; type specifies the file system type on the disk partition; flags specifies how the file system is mounted; data is a pointer to an arbitrary information structure whose content depends on the specific file being mounted System type.

After using the mount command, VFS searches for file system type information in the file_system_type linked list according to the specified file system name through file_systems. The function get_fs_type () finds the corresponding file_system_type structure in the kernel according to the type name of the specific file system:

struct file_system_type * get_fs_type (const char * name)

{

struct file_system_type * fs;

read_lock (& file_systems_lock);

fs = * (find_filesystem (name));

if (! fs && (request_module (name) == 0)) {

read_lock (& file_systems_lock);

fs = * (find_filesystem (name));

if (fs &&! try_inc_mod_count (fs-> owner))

fs = NULL;

read_unlock (& file_systems_lock);

}

return fs;

}

The function find_filesystem (name) scans the file_system pairs to find the data structure of the required file system type.

Virtual file system unmount file system

Superuser unmounts the file system using the umount command.

The unmount process must check the status of the file system and its superblocks. If the file system is being used by another process, the file system cannot be unmounted. If a file or directory of the file system is in use, the VFS inode cache may contain the corresponding VFS inode. Check the code in the cache to find if there is a VFS inode from the file system according to the device identifier where the file system is located. If there is and the usage count is greater than 0, the file system is in use and cannot be deleted. If the file system's superblock is "dirty", that is, modified, it should be written back to disk first.

The file system allows the corresponding VFS superblock to be released after being deleted, and the vfsmount data structure is disconnected from the vfsmntlist linked list and released.