{"id":393,"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:38","modified_gmt":"2020-08-22T20:26:38","slug":"this-is-the-page-title-toplevel-226","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=393","title":{"rendered":"Supported File Systems"},"content":{"rendered":"\n<title>Supported Filesystems<\/title>\nBecause it runs on almost every hardware platform, Linux must be able to\nsupport all of the filesystem types that are found on those systems. In\nprinciple, Linux <i>could<\/i> get away with simply supporting its own filesystem\ntypes, but it is often required to co-exist with other oeprating systems and a\ncommon filesystem type is the usually only way to share data between two operating\nsystems on the same system.\n<\/p>\n<p>\nHowever, deciding which filesystems to use is not simply a matter of sharing\ndata. It is also a matter of what your needs and to a limited extent the\nLinux distribution you are running. As we talked about in the sections on the\n<site id=\"96\">disk layout<\/site> and the\n<site id=\"272\">EXT2 filesystem<\/site>, a filesytem is basically nothing more than\na set of data structures on the hard disk. However, it is how these structures\nare defined and how they are used which is the difference in the various\nfilesystems. Which one you choose can have dramatic effects on your performance,\nthe reliability of the data, the time required to recover from system crashes,\nthe maximum number of files supported\nand even how specific you can controll access to the files.\n<p>\nTypically, when you install Linux, you are provided with a default and handful of\nchoice, should you not want the default. Typically, people choose the default, which\nmay be an ext2fs or ext3fs, or even a ReiserFS. The ext2fs seems to be the most\ncommon and the one referred to specifically in most texts that I know. However, that\ndoes not mean it (or any of the other default filesystems) is naturally the best\nfor your specific purpose.\n<p>\nWhen I first started using Linux, I would always choose the ext2fs (actaully there\nwasn&#8217;t much else at that time). Then I moved to the ReiserFS. It wasnt&#8217;t until I\nknew what it could do and that I wanted to use the features that I moved on to the\nXFS. This is not to say that the XFS is the best, just that I want to use the\nfeatures that is has.\n<p>\nNote that because it is relatively new, your distribution may not have the filesystem\nyou want, Linux allows to to easily add them. You can download the driver from\nthe appropriate web site, but check your distribution first. It may already be there,\njust not activated in your kernel. Also, before you download it and try to add it,\nmake sure the version of the filesystem you want is supported by the version of\nthe kernel you have. Obviously there is tight integration between the filesystem\ndrivers and the kernel. Therefore, you want to make sure that they are 100{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\ncompatible.\n<p>\nMy personal opinion is that unless you have a very specific reason to move to\nanother filesystem, then you are probably best served by using the defaults\nfor your particular distribution. That way you know the filesystem will work with\nyour kernel and the tools needed by that filesystem work correctly.\n<p>\nIn the section on the <site id=\"272\">EXT2 filesystem<\/site>, we go into details about\nthe ext2fs. Although the concepts discussed are the same for many filesystems, the\nimplementation is different, plus there are many additions or extensions each\nfilesystem provides.\n<\/p>\n<p>\nFor example, the ext3fs has the same basic features as the\next2fs, but provides journalling. In essential,  what journalling does is keep a\nrecord (or journal) of activity on the filesystem. Should the sytem crash, it is\neasier and quicker to simply re-read the journal to correct any problems. The way\nthis works is similar to the way a modern database (like Oracle) works. Since data\nis usually written in blocks (not necessarily hard disk blocks), the filesystem\nmight become corrupt if the system suddenly stopped in the middle of writing (for\nexample because of a power failure or system crash). To make sure that any resulting\nproblem are addressed, modern filesystems support the concept of a &#8220;dirty bit&#8221;. This\nis simply a marker at the beginning of the filesystem which indicates that it was\nnot unmounted properly or &#8220;cleanly&#8221; and thus the filesystem is dirty.\nWhen the system reboots, it sees that the filesystem was not unmounted cleanly and\nbegins performing the necessary checks on the entire filesystem. Naturally, the\nlarger the filesystem, the longer these checks take.\n<p>\nWell, what if the system knew what areas of the filesystem had been used? That way\nit only needs to check just those areas that were changed. Sounds like a great\nahead, but how does it keep track of what was changed? By writing the changes in the\njournal. When the system reboots, it will look for transactions (operations) in the\njournal that were not completed (pending) and reacts accordingly. It&#8217;s possible that\nyou will still loose data, since journal cannot recover data that was not yet\ncompletely written to the journal and there are cases where the safest thing to\ndo is to skip a given transaction (rollback). However, recovering from crashes takes\na matter of seconds or minutes and not hours.\n<p>\nThe first journalling filesystem with Linux support was the ReiserFS.\nAnother journalling filesystem is IBM&#8217;s JFS, which was originally written for AIX\n(the IBM version of UNIX) and the ported to OS\/2. Eventually, the OS\/2 implementation\nwas made open source and then ported to Linux. Then there is the XFS, which came\nfrom Silicon Graphics UNIX version IRIX. The XFS has the advantage that it supports\naccess controll lists (ACLs), which allow much finer control of filesystem access\nthan is possible with traditional UNIX filesystems.\n<p>\nIf you have en existing ext2fs and do not want to reboot, you can easily convert to\nthe ext2fs, plus the ext3fs can be read using the ext2fs driver (for example, if you\nmove it to another system without ext2fs support). Being just an extension to the\nexisting ext2fs, the ext3fs is very reliable. Consider how long the ext2fs\nhas been around, some people consider it &#8220;out-dated&#8221;. However, older does not\nnecessarily equate to out-dated, but it does equate to being stable and reliable.\nPlus it does provide\njournalling for system with the ext2fs without having to re-install.\n<p>\nAnother consideration is the performance of yoru filesystem. With the speed of\nCPUs and disk sub-systems today, most home users do not run into filesystem problems.\nSo, choosing a filesystem just because it has better performance is not always the\nbest decision. One thing that is important is the way in which you in particular\naccess the hard disk (your &#8220;access patterns&#8221;). Interestingly enough, the XFS and JFS\ntypically work better with the smaller files (&lt; 100 MB, if you call that small),\nwhich is what home users normally have.\n<p>\nIf it is hard to make a decision between different filesystems and want to look at\nthe performance in <i>your<\/i> environment, then I would say that the best thing to\ndo is test it in your environment. Benckmarking by others under &#8220;laboratory&#8221;\nconditions might be good to get a general idea of what the performance is. However,\nthere are a number of different factors that may bring you different results, such\nas the hardware, the applications, and usage patterns.\n<p>\nIf you need to do performance tests, test in on the exact same hardware. Even go to\nthe point where you overwrite each filesystem with the new one. Believe it or not,\nthe physical location on the disk can have a great effect on the performance. Since\nit takes longer to move the read-write heads to places further in on the disk,\nI know some admistrators who place disk intensive data (like a database) at the very\nbeginning of the disk and other things further on. So if the filesystems are\non different parts of the disk, that might effect your tests.\n<p>\nFor home users, the efficiency in which space is allocated is less of an issue.\nToday, 40Gb or even 60Gb is a <i>small<\/i> hard disk. My first hard disk was only\n20 <i>Mb<\/i>, which was 20,000 time smaller. One reason this is less of an issue\nfor home users is that they typically use IDE drives, whereas SCSI is more\ncommon of the servers businesses use. Since IDE drives are cheaper\nbyte-for-byte than SCSI, do don&#8217;t find as many home users with SCSI hard\ndrives, so it is likely that the hard disk are larger. Unless you download\neverything you have ever found on the Internet, then you are probably\nnot going to need to squeeze out every kilobyte from the hard disk.\n<p>\nRemember that data on the hard disk is typically stored in blocks of 512\nbytes. However, the various filesystem have block sizes ranging from\n512 bytes to as much as 64Kbytes. Note that regardless of the size, they\nare typically still in &#8220;power-of-two&#8221; multiples times the 512 byte block\nsize of that disk, such as 2<sup>2<\/sup>*512, 2<sup>3<\/sup>*512 or\n2<sup>4<\/sup>*512.\n<p>\nFor argument&#8217;s sake, let&#8217;s say that you have the smallest possible block\nsize and you create a file that is 513 bytes. Since it is larger than one\nblock, you obviously will need two. However, 511 bytes of the the second\nblock go unused. However, if the block size is 4K, then you loose just\nunder 3.5K of space. If you use a 64K, then you end up loosing over 60K of\nspace!\n<p>\nRealistically, this is all good theory, but it&#8217;s different in practice. If you\njust consider operating system files, you have files that range in size from\njust a few bytes to several megabytes and since they are almost never an exact\nmultiple of any block sizes, you will always loose space. The only question is\nhow much. Obviously, using the smallest block size means you loose the least\namount of space (max. 511 bytes). However, there is almost always a slight\nperformance degradation because the system needs to manage each block\nindividually and the more blocks there are, there more that needs to be\nmanaged. Furthermore, the more pieces there are, the easier it is for the\nfile to become fragmented (spread out all over the disk) and thus decrease\nperformance even further as the hard disk needs to move back and forth to\ngather all of the various pieces.\n<p>\nThe ReiserFs addresses this issue in a unique way in that it has a special\nmechanisms to manage all of the file &#8220;tails&#8221; (the extra parts that fill\nup only part of a block). The tails from multiple files are combine together\nis seperate blocks, thus descreasing the total number of blocks needed.\nHowever, I personally don&#8217;t think that this feature should be the sole reason\nfor choosing the ReiserFS. Even if you managed to save 100Mb like that, it would\nonly be 1{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63} of a 10Gb hard disk and (in my opinion) not worth worrying about.\nThe XFS solves this problem by storing small files directly within the\n<glossary>inode<\/glossary>. Once again, the savings is no longer relevant\n(in my opinion).\n<p>\nNow consider a filesystem that stores an Oracle database. You might only have\n50 files on it, an no new ones are ever added. Of the 50, 40 are less than\n100K, so you save almost nothing. The other 10 files are database files and\neach is 2 GB. The savings is not even worth the time to read this paragraph.\n<p>\nOne the othe hand, a web server or other system that has millions of small\nfiles, then the savings might amount to something significant. However, I need\nto point out the word &#8220;might&#8221;. If all you need to do is add a 20 GB hard disk\nto solve your problems, the cost of the new hard drive probably outweighs\nother factors.\n<p>\nAlso you need to consider the space required for the journalling information.\nIn most cases, it is so small by comparison to the drive that it is usually not\nworth considering. However, if you are using some kind of removeable media that\nonly has 100Mb, then the 32 Mb that the ReiserFS requires for its journal\ninformation is a big chunk!\n<p>\nAs we tal about in the <site id=\"225\">section on filesystem permissions<\/site>\nlinux uses the tradition ower-group-other, read-write-execute permissions.\nIn general, this is all that is needed for home users, or ever on\ncompany servers that run applications for users rather than having users\nlogin, such as database or web servers. However, particularly for\nfile servers, you often need even finer controll of who has access to\nwhich files and directories and what kind of access they have. This is\ndone through access controll lists (ACLs).\n<p>\nAs it&#8217;s name implies, an access controll list is a list that controls\naccess to files and directories. Instead of being able to specify\npermissions for just a single user, a single group and everyone else,\nyou can list specific users and groups. For example, you own a file and\nyou want to give read access to just a specific person (for example,\nyour boss) or to a number of people in different groups. Theorectically,\nyou <i>could<\/i> create a new group containing these people, but that\ncould mean that you need a new group for each combination. Also, groups\ncan only be created by the system administrator, so you have to wait\nuntil they got around to doing it. With ACLs, the owner of the file has\nthe ability to make changes.\n<p>\nAn important thing to keep in mind is that only the XFS has native support\nfor ACLs (at least as of this writing). There are packages available for\next2fs, ext3fs and ReiserFS. However, since XFS is also a journalling\nfilesystem, the others offer little advantage (which is why I moved\nall of my filesystems to XFS).\n<p>\nAs of this writing, Linux supports the following filesystem types:\n<li>Extended Filesystem &#8211; ext (Linux)\n<li>Second Extended Filesystem &#8211; ext2 (Linux)\n<li>Third Extended Filesystem &#8211; ext3 (Linux, journalling)\n<li>Reiser Filesystem &#8211; reiserfs (Linux, journalling)\n<li>Amgia Fast Filesystem &#8211; affs\n<li>High Performance Filesystem &#8211; hpfs (OS\/2)\n<li>IS0 9660 Filesystem &#8211; iso9660 (CD-ROM)\n<li>Minix Filesystem &#8211; Minix (Minix. first filesystem used by Linux)\n<li>FAT 16 bit  &#8211; msdos (DOS, Windows)\n<li>Virtual Fat Fielsystem &#8211;  vfat (DOS, Windows) Supports long filenames\n<li>Network Filesystem &#8211; NFS\n<li>Novell Filesystem &#8211; NCPFS (Novell)\n<li>System V Filesystem &#8211; sysv (System V Unix variants)\n<li>Uniform Filesystem &#8211; ufs ( BSD, Solarius, NeXTStep)\n<li>UMSDOS Filesystem &#8211; umsdos (Unix filesystem on DOS)\n<li>adfs\n<li>autofs\n<li>coda\n<li>coherent\n<li>cramfs\n<li>devpts\n<li>efs\n<li>hfs\n<li>jfs (Linux, journalling)\n<li>ntfs\n<li>proc\n<li>qnx4\n<li>romfs\n<li>smbfs\n<li>tmpfs\n<li>udf\n<li>xenix\n<li>xfs  Silicon Graphics&#8217; (SGI&#8217;s) IRIX\n","protected":false},"excerpt":{"rendered":"<p>Supported Filesystems Because it runs on almost every hardware platform, Linux must be able to support all of the filesystem types that are found on those systems. In principle, Linux could get away with simply supporting its own filesystem types, &hellip; <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=393\">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-393","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/393","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=393"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/393\/revisions"}],"predecessor-version":[{"id":713,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/393\/revisions\/713"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}