Linux Virtual System file exchanger profiling __linux

The most notable feature of linux® is flexibility and extensibility, such as its virtual file system exchanger (VFS). You can create file systems on a variety of devices, including traditional disks, USB flash drives, memory, and other storage devices. You can also embed the file system in another file system environment. Explore the factors that cause the VFS to be so powerful and understand the main interfaces and processes of the VFS.

The flexibility and extensibility support for Linux file systems stems directly from a set of abstract interfaces. The core of this set of interfaces is the virtual file System converter (VFS).

The VFS provides a standard set of interfaces for upper-level applications to perform file I/O to different file systems. This set of interfaces supports multiple concurrent file systems on one or more underlying devices. In addition, these file systems may not be static and can vary depending on the storage device.

VF and VFS You can also see that the VFS is also defined as the virtual file system, but the virtual file system switch is defined as a better indication of its usefulness because the virtual layer transforms (that is, multiplexing) requests across multiple file systems. The/proc file system is a lot of confusion here because it is often referred to as a virtual file system.

For example, a typical Linux desktop supports the Ext3 file system on an available hard disk and supports the ISO 9660 file system on an available CD-ROM (or a CD-ROM file system or CDFS). Because the CD-ROM can be plugged in and removed, the Linux kernel must adapt to these new file systems that contain different content and structure. Remote file systems can be accessed through the Network File system (network file System,nfs). At this point, Linux can also mount the NT File system (NTFS) partition of the Windows®/linux dual boot system from the local hard disk and be able to read and write data to it.

Finally, the removable USB Flash boot (UFD) is hot swappable, which makes up another file system. In summary, the same set of file I/O interfaces can be used in these devices to allow the underlying file systems and physical devices to be abstracted from the user (see Figure 1).
Figure 1. An abstraction layer that provides a unified interface between different file systems and storage devices

Layered Abstraction

Now, we add some concrete schemas to the abstract features provided by the Linux VFS. Figure 2 shows a high-level view of the LINUX structure from the perspective of the VFS. Above the VFS is the standard kernel system call Interface (SCI). This interface allows user space to emit calls that are converted to the kernel (in different address spaces). In this domain, the user space application that calls the POSIX open call goes through the GNU C Library (glibc) into the kernel and system calls to diversify (de-multiplexing). Finally, use Sys_open to invoke the VFS.
Figure 2. The layered architecture of the VFS

The early VFS implementation Linux is not the first operating system that contains a virtual layer to support a common file model. The early VFS implementations included the Sun's VFS (SunOS version 2.0, which occurred around 1985), and IBM and Microsoft® 's "installable File System" for IBM OS/2. These virtualized file system layer methods pave the way for the Linux VFS.

The VFS provides an abstraction layer that separates the POSIX APIs from the details of how a particular file system implements the behavior. The key here is that whether the underlying file system is ext3 or Btrfs,open, Read, Write, or close API system calls work correctly. VFS provides a common file model that is inherited by the underlying file system, which must implement behavior for various POSIX API functions. Another deep abstraction beyond the scope of the VFS hides the underlying physical devices (possibly disks, disk partitions, network storage entities, memory, or other media that can store information-even temporarily).

In addition to the details of abstracting file operations from the underlying file system, the VFS binds the underlying block device to the available file system. Let's look at the internal structure of the VFS and how it works.

The internal structure of the VFS

Before looking at the overall architecture of the VFS subsystem, let's look at the main objects used. This section explores superblock, index nodes (or inode), directory entries (or dentry), and file objects. Here, other components are also important, such as caching. But I'll discuss them in the overall architecture that follows.

Super Block

A superblock is a container for advanced metadata about a file system. A super block is a structure that exists on a disk (which is actually located in multiple locations on a disk to provide redundancy). It is the basis for processing file systems on disk because it defines the management parameters of the file system (for example, the total number of blocks, free blocks, and root index nodes).

On disk, a super block provides the kernel with information about the structure of the file system on disk. In memory, a super block provides the necessary information and status for the managed active (mounted) file system. Because Linux supports mounting multiple concurrent file systems at the same time, each super_block structure is maintained in a single list (super_blocks defined in./LINUX/FS/SUPER.C, structure in/linux/include/fs/fs.h definition).

Figure 3 provides a simplified view of the Super block and its elements. Super_block structure refers to many other structures that encapsulate other information. For example, the FILE_SYSTEM_TYPE structure maintains the name of the file system (such as ext3) and various locks and functions to obtain and delete Super_block. The File_system_type object is managed by the common Register_file system and Unregister_file system functions (see./linux/fs/file systems.c). The super_operations structure defines a large number of functions for read-write nodes and advanced operations such as re-mount. The root directory entry (Dentry) object is also cached here because it is the block device where the file system resides. Finally, there are a number of lists for managing nodes, including S_inodes (list of all nodes), S_dirty (listing all dirty nodes), S_io and S_more_io, and s_files (list of all open files for a particular file system).
Figure 3. Simplified view of super_block structure and its elements

Note that within the kernel, another administrative object called Vfsmount provides information about the file system that is mounted. The lists of these objects refer to a hyperlink and define the mount point, the name of the/dev device where the file system resides, and other advanced additional information.

Index node (inode)

Linux manages all objects in the file system through an object called an inode (the abbreviation of index node). An inode can refer to a symbol link for a file, directory, or another object. Note that because files are used to represent other types of objects (such as devices or memory), they are also represented using an inode.

The Inode I refer to here is the VFS layer Inode (resident inode). Each file system also contains an inode on disk and provides details about specific objects for a particular file system.

The VFS Inode is allocated using the slab allocator (from the Inode_cache Resources section to provide a link to an introduction to the slab allocator). The inode consists of data and operations describing the inode, the content of the inode, and the various operations that may occur on the inode. Figure 4 simply shows a VFS inode, which contains many lists, one of which points to the dentry that references the inode. It also contains object-level metadata, including familiar operating times (creation time, access time, and modification time), and owner and permission data (group ID, user ID, and permissions). The inode refers to the file operations it allows, most of which are mapped directly to the system call interface (for example, open, read, write, and flush). The inode also refers to inode-specific operations (create, lookup, link, and mkdir, and so on). Finally, there is a management structure for the data of the object represented by the address space object. An address space object is an object that manages various pages in the page cache for an inode. An address space object is used to manage pages for files and to map portions of a file to a separate process address space. An address space object has its own set of operations (Writepage, Readpage, Releasepage, and so on).
Figure 4. Simplified diagram of VFS inode

Note that you can find all of this information in./linux/include/linux/fs.h.

Directory entry (dentry)

The hierarchy of the file system is managed by another object called Dentry in the VFS. The file system has a root dentry (referenced in a hyperlink), which is the only dentry without a parent object. All other dentry have parent objects, and some dentry have child objects. For example, if you open a file made up of/home/user/name, you will create 4 Dentry objects: one for the root/, one for the root home, one for the user directory, and one for the user directory (name bar) Accounts In this way, dentry succinctly maps to the file system that is currently in use.

The Dentry object is defined by the dentry structure (in./linux/include/fs/dcache.h). It consists of a number of elements that track the relationship between entries (such as file names) in the file system and physical data. Figure 5 shows a simplified diagram of the Dentry object. The Dentry reference Super_block,super_block defines the specific file system instance that contains the object. Next is the object's parent dentry (the parent directory), followed by the child dentry contained in a list, if the object is just a directory. Then, define actions for dentry (such as hash, compare, delete, release, and so on). The name of the object is then defined, where the name is stored in the dentry rather than in the inode. Finally, a reference to the VFS Inode is provided.
Figure 5. Simplified representations of Dentry objects

Note that the Dentry object exists only in file system memory and cannot be stored on disk. Only permanent storage of file system Inode,dentry objects is intended to improve performance. You can see the full description of dentry in./linux/include/dcache.h.

File objects

There is a file object in each of the files that are open in the Linux system. This object provides information about an open instance to a specific user. Figure 6 provides a simplified view of the file object. As you can see in the diagram, the path structure provides references to Dentry and Vfsmount. A set of file operations is defined for each file, and common file operations include open, close, read, write, and flush. It then defines a set of flags and permissions, including groups and owners. Finally, define the state data for a particular file instance, such as the current offset of the file.

Figure 6. Simplified representations of File objects

Object relationships

We've looked at the various important objects in the VFS layer, and now we have a diagram showing the relationships between them. So far, I've been exploring objects from a bottom-up approach, and now we're looking at objects from the user perspective in a top-down fashion (see Figure 7).

At the top level is the open file object, which is referenced by the process's file description characters. The file object refers to the Dentry object, which references the inode. Both Inode and Dentry objects refer to the underlying Super_block object. There may be multiple file objects referencing the same dentry (when two users share the same file). Note that a Dentry object in Figure 7 also refers to another Dentry object. Here, the directory references the file, and the file in turn refers to the inode for the particular file.

Figure 7. Relationships between the main objects in the VFS

VFS schema

The internal architecture of the VFS consists of a dispatch layer (which provides file system abstraction) and many caches that improve the performance of file system operations. This section explores the interaction between the internal architecture and the main objects (see Figure 8).

Figure 8. Advanced view of the VFS layer

The two main objects that are dynamically managed in the VFS are Dentry and Inode objects. Cache these two objects to improve the performance of accessing the underlying file system. When a file is opened, the Dentry cache is populated with entries that represent the directory level (the directory level represents the path). In addition, you create an inode for the object that represents the file. Use the hash table to create the Dentry cache and assign the cache based on the object name. Dentry cached entries are allocated from the Dentry_cache slab allocator, and entries are deleted using the recently unused (LEAST-RECENTLY-USED,LRU) algorithm when there is pressure on the cache. You can find the Dentry cache-related functions in./linux/fs/dcache.c and./linux/include/linux/dcache.h.

To achieve faster lookup speeds, the Inode cache is implemented as two lists and a hash table. The first list defines the inode currently in use; the second list defines the unused inode. The inode being used is also stored in a hash table. Allocates a single Inode cache object from the Inode_cache slab allocator. You can find the functions associated with the inode cache in./linux/fs/inode.c and./linux/include/fs.h. In the present implementation, the Dentry cache dominates the inode cache. If there is a Dentry object, an Inode object will also exist in the inode cache. The lookup is performed in the Dentry cache, which causes an object to appear in the Inode cache.

Conclusion

This article explores the basic concepts of VFS and the objects that provide a unified interface for accessing different file systems. Linux has great scalability and flexibility and can be extended from subsystems. You can learn more about the VFS from the links provided in the Resources section. (Responsible editor: A6)