{"id":426,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:40","modified_gmt":"2020-08-22T20:26:40","slug":"this-is-the-page-title-toplevel-259","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=426","title":{"rendered":"The Virtual File System"},"content":{"rendered":"\nThe Virtual File System (VFS)<\/title>\n<p>\n<img decoding=\"async\" src=\"vfs.gif\">\n<p>\nFigure: A Logical Diagram of the Virtual File System<\n<p>The figure above\nshows the relationship between the Linux kernel’s Virtual File System and it’s real\nfile systems. The virtual file system must manage all of the different file systems\nthat are mounted at any given time. To do this it maintains data structures that\ndescribe the whole (virtual) file system and the real, mounted, file systems.\n<p>\nRather confusingly, the VFS describes the system’s files in terms of superblocks\nand inodes in much the same way as the EXT2 file system uses superblocks and inodes.\nLike the EXT2 inodes, the VFS inodes describe files and directories within the system;\nthe contents and topology of the Virtual File System.\nFrom now on, to avoid confusion, I will write about VFS inodes and VFS superblocks to\ndistinquish them from EXT2 inodes and superblocks.\n<p>\nAs each file system is initialised, it registers itself with the VFS.\nThis happens as the operating system initialises itself at system boot time.\nThe real file systems are either built into the kernel itself or are built as\nloadable modules. File System modules are loaded as the system needs them, so,\nfor example, if the <tt>VFAT<\/tt> file system is implemented as a kernel module,\nthen it is only loaded when a <tt>VFAT<\/tt> file system is mounted. When a block\ndevice based file system is mounted, and this includes the root file system, the\nVFS must read its superblock. Each file system type’s superblock read routine must\nwork out the file system’s topology and map that information onto a VFS superblock\ndata structure. The VFS keeps a list of the mounted file systems in the system\ntogether with their VFS superblocks. Each VFS superblock contains information and\npointers to routines that perform particular functions.\nSo, for example, the superblock representing a mounted EXT2 file system contains\na pointer to the EXT2 specific inode reading routine. This EXT2 inode read routine,\nlike all of the file system specific inode read routines, fills out the fields in a\nVFS inode. Each VFS superblock contains a pointer to the first VFS inode on the file\nsystem. For the root file system, this is the inode that represents the\n<tt>``\/''<\/tt> directory. This mapping of information is very efficient for the\nEXT2 file system but moderately less so for other file systems.\n<p>\nAs the system’s processes access directories and files, system routines are called\nthat traverse the VFS inodes in the system.\n<p>\nFor example, typing <command>ls<\/command> for a directory or\n<command>cat<\/command> for a file cause the the\nVirtual File System to search through the VFS inodes that represent the file system.\nAs every file and directory on the system is represented by a VFS inode, then a number\nof inodes will be being repeatedly accessed.\nThese inodes are kept in the inode cache which makes access to them quicker.\nIf an inode is not in the inode cache, then a file system specific routine must be\ncalled in order to read the appropriate inode.\nThe action of reading the inode causes it to be put into the inode cache and\nfurther accesses to the inode keep it in the cache.\nThe less used VFS inodes get removed from the cache.\n<p>\nAll of the Linux file systems use a common buffer cache to cache data buffers\nfrom the underlying devices to help speed up access by all of the file systems to the\nphysical devices holding the file systems.\n<p>\nThis buffer cache is independent of the file systems and is integrated into the\nmechanisms that the Linux kernel uses to allocate and read and write data buffers.\nIt has the distinct advantage of making\nthe Linux file systems independent from the underlying media and from the\ndevice drivers that support them.\nAll block structured devices register themselves with the Linux kernel and\npresent a uniform, block based, usually asynchronous interface.\nEven relatively complex block devices such as SCSI devices do this.\nAs the real file systems read data from the underlying physical disks, this\nresults in requests to the block device drivers to read physical blocks from the\ndevice that they control.\nIntegrated into this block device interface is the buffer cache.\nAs blocks are read by the file systems they are saved in the global buffer cache\nshared by all of the file systems and the Linux kernel.\nBuffers within it are identified by their block number and a unique identifier for\nthe device that read it.\nSo, if the same data is needed often, it will be retrieved from the buffer cache\nrather than read from the disk, which would take somewhat longer.\nSome devices support read ahead where data blocks are speculatively read just in\ncase they are needed.\n<p>\nThe VFS also keeps a cache of directory lookups so that the inodes\nfor frequently used directories can be quickly found.\n<p>\nAs an experiment, try listing a directory that you have not listed recently.\nThe first time you list it, you may notice a slight pause but the second time\nyou list its contents the result is immediate.\nThe directory cache does not store the inodes for the directories itself; these\nshould be in the inode cache, the directory cache simply stores the mapping between\nthe full directory names and their inode numbers.\n<p>\n<h3>Finding a File in the Virtual File System<\/h3>\n<p>\nTo find the VFS inode of a file in the Virtual File System, VFS must resolve the\nname a directory at a time, looking up the VFS inode representing each of the\nintermediate directories in the name.\nEach directory lookup involves calling the file system specific lookup whose address\nis held in the VFS inode representing the parent directory.\nThis works because we always have the VFS inode of the root of each file system\navailable and pointed at by the VFS superblock for that system.\nEach time an inode is looked up by the real file system it checks the directory\ncache for the directory.\nIf there is no entry in the directory cache, the real file system gets the VFS\ninode either from the underlying file system or from the inode cache.\n<p>\n<h3>Creating a File in the Virtual File System<\/h3>\n<p>\nThe <command>update<\/command>\ncommand is more than just a command; it is also a daemon.\nWhen run as superuser (during system initialisation) it will periodically flush\nall of the older dirty buffers out to disk. It does this by calling a system service\nroutine that does more or less the same thing as <tt>bdflush<\/tt>.\nWhenever a dirty buffer is finished with, it is tagged with the system time that\nit should be written out to its owning disk. Every time that <command>update<\/command>\nruns it looks at all of the dirty buffers in the system looking for ones with an\nexpired flush time. Every expired buffer is written out to disk.\n<p>\n<h2>The <directory>\/proc<\/directory> File System<\/h2>\n<p>\nThe <directory>\/proc<\/directory> file system really shows the power of the Linux Virtual File System.\nIt does not really exist (yet another of Linux’s conjuring tricks), neither\nthe <directory>\/proc<\/directory> directory nor its subdirectories and its files actually exist.\nSo how can you <command>cat<\/command> <directory>\/proc\/devices<\/directory>?\nThe <directory>\/proc<\/directory> file system, like a real file system, registers\nitself with the Virtual File System.\nHowever, when the VFS makes calls to it requesting inodes as its files and directories\nare opened, the <directory>\/proc<\/directory> file system creates those files and\ndirectories from information within the kernel.For example, the kernel’s\n<directory>\/proc\/devices<\/directory> file is generated from the kernel’s\ndata structures describing its devices.\n<p>\nThe <directory>\/proc<\/directory> file system presents a user readable window into the kernel’s\ninner workings.\nSeveral Linux subsystems, such as Linux kernel modules described in\n<site id=\"298\">the section on kernel modules<\/site>, create entries in\nthe <directory>\/proc<\/directory> file system.\n<p>\n","protected":false},"excerpt":{"rendered":"<p>The Virtual File System (VFS) Figure: A Logical Diagram of the Virtual File System< The figure above shows the relationship between the Linux kernel’s Virtual File System and it’s real file systems. The virtual file system must manage all of … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=426\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-426","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/426","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=426"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/426\/revisions"}],"predecessor-version":[{"id":762,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/426\/revisions\/762"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=426"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}