{"id":255,"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:00","modified_gmt":"2020-08-22T20:26:00","slug":"this-is-the-page-title-toplevel-90","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=255","title":{"rendered":"Disk Layout"},"content":{"rendered":"\n<title>Disk Layout<\/title>\n<p>\nOriginally, you could only get four partitions on a hard disk. Though this\nwas not a major issue at first, as people got larger hard disks, there was a\ngreater need to break things down in a certain structure. In addition, certain\nOSes needed a separate space on which to swap. If you had one <glossary>partition<\/glossary> for your root file system, one for swap, one for user information, and one for common\ndata, you would have just run out.\n<\/p>\n<p>\nTo solve the problem and still maintain\nbackward compatibility, DOS-based machines were able to create an extended\npartition that contained logical partitions within it. Other systems, like SCO,\nallow you to have multiple file systems within a single <glossary>partition<\/glossary>\nto overcome the limitation.\n<\/p>\n<p>\nTo be able to access data on your hard disk, there has to\nbe some pre-defined structure. Without structure, the unorganized data end up\nlooking like my desk, where there are several piles of papers that I have to\nlook though to find what I am looking for. Instead, the layout of a hard disk\nfollows a very consistent pattern so consistent that it is even possible for\ndifferent operating systems to share the hard disk.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"Where is a hard disk's partition table located?\" \/>\n<concept id=\"\" description=\"A  hard disk's partition table is located ath the very beginning of the hard disk.\" \/>\n<question id=\"\" type=\"mc\" text=\"How large is the partition table?\" \/>\n<question id=\"\" type=\"tf\" text=\"A Linux partition table is twice the size of that for Windows.\" \/>\n<question id=\"\" type=\"tf\" text=\"The first partition must always be active.\" \/>\n<p>\nBasic to this structure is the concept of a <i>partition<\/i>. A <glossary>partition<\/glossary>\ndefines a portion of the hard disk to be used by one <glossary>operating system<\/glossary>\nor another. The <glossary>partition<\/glossary> can\nbe any size, even the entire hard disk. Near the very beginning of the disk is\nthe <i>partition table<\/i>. The <glossary>partition<\/glossary>\ntable is only 512 bytes but can still define where each <glossary>partition<\/glossary>\nbegins and how large it is. In addition, the partition table indicates which of the partitions\nis <i>active<\/i>. This decides which <glossary>partition<\/glossary>\nthe system should go to when looking for an <glossary>operating system<\/glossary>\nto boot. The <glossary>partition<\/glossary>\ntable is outside of any partition.\n<\/p>\n<p>\nOnce the system has determined which <glossary>partition<\/glossary>\nis active, the <glossary>CPU<\/glossary>\nknows to go to the very first block of data within that partition and begin executing\nthe instructions there. However, if <glossary>LILO<\/glossary> is setup to run out of your <glossary>master boot block<\/glossary>, it doesn&#8217;t care\nabout the <glossary>active partition<\/glossary>. It does what you tell it.\n<\/p>\n<p>\nTypically, special control structures that impose an additional structure are created at the\nbeginning of the <glossary>partition<\/glossary>.\nThis structure makes the partition a <i>file system<\/i>.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What 'control structures' at the beginning of a Linux partition define the actual filesystem?\" \/>\n<concept id=\"\" description=\"There are two control structures at the beginning of the file\nsystem: the superblock and the inode table\" \/>\n<question id=\"\" type=\"mc\" text=\"What information does the superblock contain?\" \/>\n<concept id=\"\" description=\"On the ext2 file system copies of the superblock are stored at regular intervals.\" \/>\n<p>\nThere are two control structures at the beginning of the file\nsystem: the <glossary>superblock<\/glossary> and the <glossary>inode table<\/glossary>. The superblock\ncontains information about the type of file system, its size, how many data\nblocks there are, the number of free inodes, free space available, and where the\ninode table is. On the ext2 <glossary>filesystem<\/glossary>,\ncopies of the <glossary>superblock<\/glossary>\nare stored at regular intervals for efficiency and in case the original gets\ntrashed.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What term is used for the process of connecting to a file system in order to be able to access it?\" \/>\n<question id=\"\" type=\"mc\" text=\"What command is used to connect to a file system in order to be able to access it?\" \/>\n<question id=\"\" type=\"mc\" text=\"Which file contains a list of filesystems to be mounted when the system first boots?\" \/>\n<question id=\"\" type=\"mc\" text=\"Which file contains a list of remote filesystems to be mounted when the system first boots?\" \/>\n<question id=\"\" type=\"tf\" text=\"The \/etc\/fstab file contains only local filesystem to be mounted.\" \/>\n<concept id=\"\" description=\"The \/etc\/fstab file contains both local and remote filesystem to be mounted.\" \/>\n<p>\nMany users are not aware that different file systems reside on\ndifferent parts of the hard disk and, in many cases, on different physical\ndisks. From the users perspective, the entire directory structure is one unit\nfrom the top (\/) down to the deepest\nsubdirectory. To carry out this deception, the system <glossary>administrator<\/glossary>\nneeds to <i>mount<\/i> file systems by mounting the <glossary>device node<\/glossary> associated with the file\nsystem (e.g., \/dev\/home) onto a <i>mountpoint<\/i> (e.g., <directory>\/home<\/directory>). This can be done either manually, with the <command>mount<\/command> command,\nor by having the system do it for you when it boots. This\nis done with entries in <filecontents type=\"fstab\">\/etc\/fstab<\/filecontents>.\n<\/p>\n<p>\nConceptually, the mountpoint serves as a detour sign for the system.\nIf there is no file system mounted on the mountpoint, the system can just drive\nthrough and access what&#8217;s there. If a file system is mounted, when the system\ngets to the mountpoint, it sees the detour sign and immediately diverts in\nanother direction. Just as roads, trees, and houses still exist on the other\nside of the detour sign, any file or directory that exists underneath the\nmountpoint is still there. You just cant get to it.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What happens to files a directories in a mountpoint when a filesystem is mounted onto it?\" \/>\n<p>\nLet&#8217;s look at an example. You have create a filesystem on the first partition of your second hard disk, so the device node would be <device>\/dev\/hdb1<\/device>. You want to mount this file system onto the directory. <directory>\/home<\/directory>.\nLet&#8217;s say that when you first installed the system and before you first mounted\nthe <device>\/dev\/hdb1<\/device> file system, you created some users with their home directories in \/home. For example, <directory>\/home\/jimmo<\/directory>. When you do finally <glossary>mount<\/glossary>\nthe <device>\/dev\/home<\/device> file system onto the <directory>\/home<\/directory> directory, you no\nlonger see <directory>\/home\/jimmo<\/directory>. It is still there, but once the system reaches the <directory>\/homes<\/directory> directory, it is redirected somewhere else.\n<\/p>\n<p>\nThe way Linux accesses\nits file systems is different from the way a lot of people are accustomed to it.\nLet&#8217;s consider what happens when you open a file. All the program needs to know\nis the name of the file, which it tells the <glossary>operating system<\/glossary>,\n which then has to convert it to a physical location on this disk. This usually\nmeans converting it to an <glossary>inode<\/glossary> sfirst.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What mechanism does Linux use to access different filesystem types?\" \/>\n<p>\nBecause the conversion between a file name and the\nphysical location on the disk will be different for different file system types,\nLinux has implemented a concept called the Virtual File System (VFS) layer. When a\nprogram makes a <glossary>system call<\/glossary>\nthat accesses the file system (such as open), the <glossary>kernel<\/glossary>\nactually calls a function within the VFS layer. It is then the VFS&#8217;s\nresponsibility to call the file-system-specific code to access the data. The figure\nbelow shows what this looks like graphically.\n<\/p>\n<p>\n<img decoding=\"async\" src=\"vfs.png\" width=391 HEIGHT=352 BORDER=0 usemap=\"#vfs_map\">\n<map name=\"vfs_map\">\n<area shape=\"RECT\" coords=\"3,1,388,63\" href=\"popup#Files and Filesystems#Different processes could be writing to different filesystems.\">\n<area shape=\"RECT\" coords=\"3,66,387,135\" href=\"popup#Files and Filesystems#The Virtual Filesystem Layer (VFS) hides the details of actual filesystem from the processes.\">\n<area shape=\"RECT\" coords=\"25,150,371,218\" href=\"popup#Files and Filesystems#The drivers for the specific filesystem are called by the VFS.\">\n<area shape=\"RECT\" coords=\"71,227,330,292\" href=\"popup#Files and Filesystems#The buffer cache stores recently accessed data so that it does not need to be repeatedly read from the hard disk. \">\n<area shape=\"RECT\" coords=\"90,301,303,349\" href=\"popup#Files and Filesystems#The device drivers access the physical hardware.\">\n<\/map>\n<p>\n<icaption>Image &#8211; File System Layers (<b>interactive<\/b>)<\/icaption>\n<\/p>\n<concept id=\"\" description=\"Linux has implemented a concept called the Virtual File System (VFS) layer to simply accessing different filesystem types using a common interface.\" \/>\n<concept id=\"\" description=\"Because it has to interact with every file system type,\nthe VFS has a set of functions that every file system implements.\" \/>\n<p>\nBecause it has to interact with every file system type,\nthe VFS has a set of functions that every file system implements. It has to know\nabout all the normal operations that occur on a file such as opening, reading,\nclosing, etc., as well as know about file system structures, such as\ninodes.\n<\/p>\n<p>\nIf you want more details, there is a <site id=\"278\">whole section on the VFS<\/site>.\n<p>\nTo address certain problems, the Second Extended File System (ext2fs) was developed. This is an enhanced version of the Extended File System (extfs). The\next2fs was designed to fix some problems in the extfs, as well as add some\nfeatures. Linux supports a larger number of other filesystems, but as of this writing,\nthe ext2fs seems to be the most common. In the following discussion we will be talking\nspecifically about the ext2fs in order to explain how inodes work. Although the details\nare specific to the ext2fs, the concepts apply to many other filesystems.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What information is stored in the inode?\" \/>\n<p>\nAmong other things that the <glossary>inode<\/glossary>\nkeeps track of are file types and <glossary>permissions<\/glossary>,\nnumber of links, owner and group, size of the file, and when it was last modified.\nIn the <glossary>inode<\/glossary>, you will also find 15 pointers to the actual data on\nthe hard disk.\n<\/p>\n<p>\nNote that these are <i>pointers<\/i> to the data and not the\ndata itself. Each one of the 15 pointers to the data is a block <glossary>address<\/glossary>\non the hard disk. For the following discussion, please refer to the figure below.\n<\/p>\n<a onclick=\"opennew('{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}CURRENT_DIRECTORY{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\/inodea.gif',458,514)\" >\n<img loading=\"lazy\" decoding=\"async\" src=\"inodec.gif\" width=\"514\" height=\"458\" border=\"0\" usemap=\"#inode_map\">\n<\/a>\n<map name=\"inode_map\">\n<area shape=\"RECT\" coords=\"447,45,510,130\" href=\"popup#Inodes#Pointers in the inode table point directly to just a few data blocks.\">\n<area shape=\"RECT\" coords=\"2,283,85,306\" href=\"popup#Inodes#Pointers in the inode table point directly to just a few data blocks.\">\n<area shape=\"RECT\" coords=\"208,200,413,285\" href=\"popup#Inodes#For the indirect data blocks, the pointer in the inode table points to a block, which in turn points to the actual data.\">\n<area shape=\"RECT\" coords=\"2,353,95,378\" href=\"popup#Inodes#For the indirect data blocks, the pointer in the inode table points to a block, which in turn points to the actual data.\">\n<area shape=\"RECT\" coords=\"223,292,510,372\" href=\"popup#Inodes#For the doubly indirect data blocks, the pointer in the inode table points to a block, which in turn points to a data block, which then points to the actual data.\">\n<area shape=\"RECT\" coords=\"3,382,95,406\" href=\"popup#Inodes#For the doubly indirect data blocks, the pointer in the inode table points to a block, which in turn points to a data block, which then points to the actual data.\">\n<area shape=\"RECT\" coords=\"223,377,510,456\" href=\"popup#Inodes#For the triply  indirect data blocks, the pointer in the inode table must go three additional levels before they reach the actual data.\">\n<area shape=\"RECT\" coords=\"0,409,95,441\" href=\"popup#Inodes#For the triply  indirect data blocks, the pointer in the inode table must go three additional levels before they reach the actual data.\">\n<area shape=\"RECT\" coords=\"4,1,90,4401\" href=\"popup#The inode table#The inode table contains 15 pointers that either point directly to data or to block which themselves contains pointers.\">\n<\/map>\n<p>\n<b>Figure &#8211; Inodes Pointing to Disk Blocks<\/b>\n<p>\nEach of these blocks is 1,024 bytes. Therefore,\nthe maximum file size on a Linux system is 15KiB. Wait a minute! That doesn&#8217;t\nsound right, does it? It isn&#8217;t. If (and that&#8217;s a big if) all of these pointers\npointed to data blocks, then you could only have a file up to 15KiB. However,\ndozens of files in the <directory>\/bin<\/directory> directory alone are larger than 15KiB. Hows that?\n<\/p>\n<p>\nThe answer is that only 12 of these blocks actually point to data, so there is\nreally only 12KiB that you can access directly. These are referred to as data\nblocks or direct data blocks. The thirteenth pointer points to a block on the hard disk outside of the inode table that actually contains the real pointers to the data. These are the <i><b>indirect<\/b><\/i>\ndata blocks and contain 4-byte values, so there are 128 of them in each block.\nIn the figure above, the thirteenth entry is a pointer to block 567. Block 567\ncontains 128 pointers to indirect data blocks. One of these pointers points to\nblock 33453, which contains the actual data. Block 33453 is an indirect data\nblock.\n<\/p>\n<p>\nBecause the data blocks that the 128 pointers pointed to in block 567 each\ncontain 512 bytes of data, there is an additional 65KiB of data. So, with 12KiB for\nthe direct data blocks and 65KiB for the indirect data blocks, we now have a\nmaximum file size of 77KiB.\n<\/p>\n<p>\nHmmm. Still not good. There are files on your system larger than 77KiB. So that\nbrings us to triplet 13. This points not to data blocks, not to a block of\npointers to data blocks, but to blocks that point to blocks that point to data\nblocks. These are then the  data blocks.\n<\/p>\n<p>\nIn the figure, the fourteenth pointer contains a pointer to block 5601. Block\n5601 contains pointers to other blocks, one of which is block 5151. However,\nblock 5151 does not contain data, but even more pointers. One of these pointers\npoints to block 56732, and it is block 56732 that finally contains the data.\n<\/p>\n<p>\nWe have a block of 128 entries that each point to a block that each contains\n128 pointers to 512 byte data blocks. This gives us 8Mb, just for the\ndouble-indirect data blocks. At this point, the additional size gained by the\nsingle-indirect and direct data blocks is negligible. Therefore, lets just say\nwe can access more than 8Mb. Now, that&#8217;s much better. You would be hard-pressed\nto find a system with files larger than 8Mb (unless we are talking about large\ndatabase applications). However, were not through yet. We have one pointer left.\n<\/p>\n<question id=\"206\" text=\"In an ext2fs inode table, how many levels of pointers to data blocks are there?\" \/>\n<p>\nSo, not to bore you with too many of you, lets do the math quickly. The last pointer\npoints to a block containing 128 pointers to other blocks, each of which points\nto 128 other blocks. At this point, we already have 16,384 blocks. Each of these\n16,384 blocks contain 128 pointers to the actual data blocks. Here we have\n2,097,152 pointers to data blocks, which gives us a grand total of\n1,073,741,824, or 1Gb, of data (plus the insignificant 8MB we get from the\ndouble-indirect data blocks). As you might have guessed, these are the\ntriple-indirect data blocks.In Figure 0-7 pointer 13 contains a pointer to block\n43. Block 42 contains 256 pointers, one of which points to block 1979. Block\n1979 also contains 256 pointers, one of which points to block 988. Block 988\nalso contains 256 pointers, though  pointers point to the actual data. For\nexample, block 911.\n<\/p>\n<question id=\"199\" text=\"An ext2 filesystem can be how large?\" \/>\n<concept id=\"151\" description=\"An ext2 filesystem can be 4 TB.\" \/>\n<p>\nIf we increase the block size to 4k (4096 bytes), we end up with more\npointers in each of the indirect blocks so they can point to more blocks. In\nthe end, we have files the size of 4Tb. However, because the size field in the\n<glossary>inode<\/glossary> is a 32-bit value, we max out at\n4Gb.\n<\/p>\n<p>\nIf you want more details, there is a <site id=\"272\">whole section on the ext2fs<\/site>.\n<p>\nLinux&#8217;s support for file systems is without a doubt the most extensive of any\noperating system. In addition to &#8220;standard linux&#8221; file systems,\nthere is also support for FAT, VFAT, ISO9660 (CD-ROM), <glossary>NFS<\/glossary>,\nplus file systems mounted from Windows machines using Samba (via the <glossary>SMB<\/glossary> protocol). Is that all? Nope! There are also drivers to support several compressed formats such as stacker and double-space. The driver for the Windows\nNT file system (NTFS) can even circumvent that &#8220;annoying&#8221; <glossary>security<\/glossary>.\n<\/p>\n<p>\n<strong>Warning:<\/strong> I have seen Linux certification prep books that talk about the the inode being a &#8220;unique&#8221; number. This can be extremely misleading. While it is true that any given inode will only appear once in the <em>inode table<\/em>, this does <strong>not<\/strong> mean that multiple files cannot have the same inode. If they do, then they point to the same data on the hard disk, despite having different names.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Disk Layout Originally, you could only get four partitions on a hard disk. Though this was not a major issue at first, as people got larger hard disks, there was a greater need to break things down in a certain &hellip; <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=255\">Continue reading <span class=\"meta-nav\">&rarr;<\/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-255","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/255","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=255"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/255\/revisions"}],"predecessor-version":[{"id":545,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/255\/revisions\/545"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=255"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}