1. Virtual File System
1.1. Basic objects in the virtual file system layers
- A file is something that can be read and written. The file is placed in memory. Placement in memory is in accordance with the concept of unix file descriptors.
- Inode represents basic objects in the file system. Inodes can be ordinary files, directories, symbolic links and so on. Virtual file systems do not have clear differences between objects, but refer to the implementation of file systems that provide appropriate behavior. High-level kernels handle different objects differently.
- File and inode are almost similar between the two. But there are important differences between the two. There is something that has an inode but does not have a file, for example a symbolic link. There are also files that do not have inodes such as pipes and sockets.
- The file system is a collection of inodes with one distinguishing inode, namely root. Other inodes are accessed starting from the root inode and searching the file name to go to the other inode. The file system has several characteristics that cover all the inodes in the file system. One of the most important is blocksize.
- Inode name. All inodes in the file system are accessed by name. Even though searching for inode names can be too heavy for some systems, virtual file systems on linux keep track of the cache and names of recently used inodes to improve performance. The cache is in memory as a tree, this means that if any inode of the file is in the cache, then the parent of the inode is also in the cache.
The virtual file system layer handles all file name path settings and converts them into entries in the cache before allowing the file system to access them. There are exceptions to the target of the symbolic link, which will be accessed directly by the file system. The file system is expected to interpret it.
1.2. Inode Operations
Linux stores cache of active inodes as well as from previously accessed inodes. There are 2 paths where this inode can be accessed. The first was mentioned earlier, each entry in the cache points to an inode and keeps the inode in the cache. The second is through the hash table inode.
Each inode has an 8-bit address that matches the address of the superblock system file and the inode number. Inodes with the same hash value are then arranged in a doubly linked list.
Changes to the cache involve adding and deleting entries from the cache itself. Entries that are no longer needed will be unhashed so they will not appear in subsequent searches.
Operations that are expected to change the cache structure must be locked during making changes. Unhash does not require semaphores because this can be done atomically in kernel lock. Many file operations require a 2 step process. The first is to search for names in the directory. The second step is to perform operations on the files that have been found. To ensure there are no incompatible processes between the two processes, after the second process, the virtual file system protocol must check that the parent entry remains the parent of its child entry. What’s interesting about cache locking is the rename process, because it changes 2 entries in one operation.
2. Linux File System
2.1. EXT2 File System
EXT2 is a powerful file system on linux. EXT2 is also one of the most powerful file systems and is the basis of all Linux distributions. In the EXT2 file system, the data files are stored as data blocks. This data block has the same length and although the length varies between EXT2 file systems, the block size is determined when the file system is created with the mk2fs command. If the block size is 1024 bytes, then a file with a size of 1025 bytes will use 2 blocks. This means we throw half a block per file.
EXT2 defines the file system topology by giving the meaning that every file on the system is associated with an inode data structure. An inode shows which blocks in a file about each file’s permissions, file modification times, and file types. Each file in the EXT2 file system consists of a single inode and each inode has a unique identification number. System file inodes are stored in the inode table. The directory in the EXT2 file system is a special file containing a pointer to the inode of each of the contents of that directory.
Figure 7–3. EXT2 File System Structure
Figure 7–4. Inode EXT2 File System
a. Inode dalam EXT2
Inode is the basic framework that builds EXT2. The inodes of each block are stored in an inode table together with a bit map that causes the system to know which inodes have been allocated which inode funds have not been allocated. MODE: contains information, what inode and access permissions that the user has. OWNER INFO: user or grop that has a file or directory SIZE: size of file in bytes TIMESTAMPS: when was the inode creation time and the time it was last modified. DATABLOKS: pointer to the block that contains data.
EXT2 inode can also refer to special devices, which specific devices are not files, but can handle programs so that programs can access the device. All device files in the / dev directory can help programs access devices.
b. Superblock in EXT2
Superblocks contain information about the base size and shape of the file system. The information in it allows the file system manager to use and maintain the file system. Normally, only the superblock is in group 0 block when the file system is mounted but each group block contains duplicates to protect if the file system becomes corrupted. The information contained is:
- Magic Number. assured the software that this is the superblock of the EXT2 file system.
- Revision Level shows the major and minor revisions of the file system.
- Mount Count and Maximum Mount Count shows the system if a check must be made and the maximum mount allowed before e2fsck is run.
- Blocks per Size are large blocks in the file system, for example 1024 bytes.
- Blocks per Group are blocks per group.
- Block Group Number block group number that contains copy from the superblock.
- Free Blocks the number of empty blocks in the file system.
- Free Inode many empty inodes in the file system.
- First Inode. inode number in the first inode in the file system, the first inode in the EXT2 root file system is the “/” directory.
2.2. EXT3 File System
EXT3 is an enhancement of the EXT2 file system. This increase has several advantages, including:
- After a resource failure , “unclean shutdown”, or system damage, the EXT2 file system must go through the checking process with the e2fsck program. This process can waste time so the boot process becomes very long, especially for large disks that contain a lot of data. In this process, all data cannot be accessed.
- The journals provided by EXT3 cause no need to check the data after a system failure. EXT3 is only checked for hardware damage such as hard disk damage, but this is very rare. The time it takes EXT3 file system after “unclean shutdown” does not depend on the size of the file system or the number of files, but depends on the size of the journal used to maintain consistency. The default journal size takes about a second to recover, depending on hardware speed.
- Data integrity . EXT3 guarantees data integrity after damage or “unclean shutdown”. EXT3 allows us to choose the type and type of protection from the data.
- Speed . Instead of writing data more than once, EXT3 has a greater throughput than EXT2 because EXT3 maximizes the movement of the hard disk head. We can choose three journal modes to maximize speed, but data integrity is not guaranteed.
- Easy to do migration . We can move from EXT2 to EXT3 systems without reformatting.
2.3. Sistem Berkas Travel
Reiser file system has a fast journal. The characteristics are similar to EXT3 file system. The file system reiser is based on a fast balance tree. Balance tree is superior in terms of performance, with a more complicated algorithm of course.
Reiser file system is more efficient in utilizing disk space. If we write a file 100 bytes, it is only placed in one block. Other file systems place it within 100 blocks. Reiser file system does not have a fixed allocation for inodes. Resier file systems can save disks up to 6 percent.
2.4. File System X
X file system is also a file system journal. The X file system was created by SGI and used in the SGI IRIX operating system. The X file system is also available for Linux under the GPL license. The X file system uses B-tree to handle a large number of files. X file systems are used on large servers.
2.5. Proc File System
Proc File System Proc File System shows how great the virtual file system that is on linux. Proc file system actually does not exist physically, both the sub-sectors, as well as the files that are in it. The proc file system is registered by the linux virtual file system, if the virtual file system calls it and requests the inodes and files, the proc file system creates the file with information in the kernel. For example, the / proc / devices belonging to the kernel are made from kernel structure data that describes the device.
3. Orthogonal File System Division
Shareable dan Unshareable.
- Shareable. The contents can be shared (shared) with other systems, to save space.
- Unshareable. The contents cannot be shared with other systems, usually for security reasons.
Variable and Static
- Variable. The contents are often changing.
- Static. Once created, it is unlikely that the contents will change. Can change if there is interference with the admin system.
References
This book is presented from the Joint Working Group 21–28 IKI-20230 Even Semester 2002/2003, by the Joint Working Group 21–28 IKI-20230 Even Semester 2002/2003, for anyone who wants to learn the Operating System. The book’s drafting team is as follows:
Group 21 (Coordinator)
Dhani Yuliarso, Fernan, Hanny Faristin, Melanie Tedja, Paramanandana DM, Widya Yuwanda.
Group 22 (Chapter 1)
Budiono Wibowo, Agus Setiawan, Baya UHS, Budi A. Azis Dede Junaedi, Heriyanto, Muhammad Rusdi.
Group 23 (Chapter 2)
Indra Agung, Ali Khumaidi, Arifullah, Baihaki AS, Christian KF Daeli, Eries Nugroho, Eko Seno P., Habrar, Haris Sahlan.
Group 24 (Chapter 3)
Adzan Wahyu Jatmiko, Agung Pratomo, Dedy Kurniawan, Samiaji Adisasmito, Zidni Agni.
Group 25 (Chapter 4)
Nasrullah, Amy S. Indrasari, Ihsan Wahyu, Inge Evita Putri, Muhammad Faizal Ardhi, Muhammad Zaki Rahman, N. Rifka N. Liputo, Nelly, Nur Indah, R. Ayu P., Sita AR
Group 26 (Chapter 5)
Rakhmad Azhari, Adhe Aries, Adityo Pratomo, Aldiantoro Nugroho, Framadhan A., Pelangi, Satrio Baskoro Y.
Group 27 (Chapter 6)
Teuku Amir FK, Alex Hendra Nilam, Anggraini W., Ardini Ridhatillah, R. Ferdy Ferdian, Ripta Ramelan, Suluh Legowo, Zulkifli.
Group 28 (Chapter 7)
Operating System: IKI-20230 Lecture Material by the Joint Working Group 21–28 IKI-20230 Even Semester 2002/2003
$ Revision: 1.3.0.0 $ Edition
Published September 30, 2003
Copyright (2003) © 2003 by Work Group Affiliation 21–28 IKI-20230 Evening Semester 2002/2003.
Please copy, distribute and / or, modify parts of the document — $ Revision: 1.3.0.0 $ — — composed by the Working Group 21–228 IKI-20230 Even Semester 2002/2003, in accordance with the provisions of the “GNU Free Documentation License version 1.1 “or later version of the FSF (Free Software Foundation); without the “Invariant” section, without the “Front-Cover” text, and without the “Back-Cover” text. Appendix A contains a complete copy of the license. This provision does NOT apply to parts and / or quotations not composed by Joint Working Groups 21–28 IKI-20230 Even Semester 2002/2003.
Revision Note
Revisi 1.3 30–09–2003 Revised by: RMS46
This revision was edited by Rahmat M. Samik-Ibrahim: continuing to improve layout and indexing.
Revisi 1.2 17–09–2003 Revised by: RMS46
This revision was edited by Rahmat M. Samik-Ibrahim: continuing improvements.
Revisi 1.1 01–09–2003 Revised by: RMS46
This revision was edited by Rahmat M. Samik-Ibrahim: to improve the structure of SGML, without too much changing the contents of the book.
Revisi 1.0 27–05–2003 Revised by: RMS46
Recompile, and do a little tidying.
Revision 0.21.4 05–05–2003 Revised by: Group 21 File tidying and adding entities.
Revision 0.21.3 29–04–2003 Revised by: Group 21 Changes by perfecting the file name.
Revision 0.21.2 24–04–2003 Revised by: Group 21
Change the Preface.
Revision 0.21.1 21–04–2003 Revised by: Group 21
Add Bibliography and Index.
Revision 0.21.0 26–03–2003 Revised by: Group 21 Initiating the Operating System lecture group work.
Christiono H, Arief Purnama LK, Arman Rahmanto, Fajar, Muhammad Ichsan, Rama P. Tardan, Unedo Sanro Simon.
