The Implementation and Operation of the EXT3 File System

Contents

Executive summary

Background

Mechanics required for a journaling file system to operate

Operations needed to create a file with the EXT3 file system

The mechanism required to update the contents of a file

How the EXT3 file system journal is utilized following an interrupted write operation

Conclusion

References

Executive summary

This report aims to discuss how the third extended file system is implemented and operates subsequently. The ext3 file system is used mainly on Linux operating systems and distros to manage data and files. This report will offer an overview of the third extended file system, but will more closely focus on its journaling mechanism, which enables a system to restore corrupted or lost data in manner of minutes. To go into more detail this report will discuss: the underlying mechanics required for the third extended file system to properly function and operate, the operations needed for the third extended file system to create a file, the integral mechanism required to update the contents of a file and how the third extended file system can utilize its journaling mechanism when a write operation is interrupted before being committed. Through discussing these points this report hopes to allow its audience to come to a consensus on the advantages which the third extended file system offers, as well as offering an insight  and deeper knowledge into the mechanics and inner workings of the third extended file system.  

Background

The third extended filesystem (ext3) is an extension of previous second extended filesystem (ext2), with the addition of the journaling mechanism being the only major difference (Chen, et al., 2017). Journaling filesystems utilize journals to journal changes which occur during the file systems disk writing process (Hyun, et al., 2010). It is used as a means of correcting any errors or in some cases crashes which may occur in an objectively faster manner, as compared to fschk command which served the same purpose in ext2 but took hours ,instead, of minutes (Chen, Tan, Wu, & Xie, 2014). On the systems next boot up, the ext3 file systems journal is checked for any inconsistencies in order to address any corruptions or un-updated files (Chen, et al., 2017). Ext3 allows three types of journaling which includes write back mode, ordered mode and data mode. In write back mode, only the metadata is journaled, and the data is written directly to their set locations (Fairbanks, Xia, & Iii, 2009). Ordered journaling mode like the write back mode only journals metadata but the difference being it writes the data before the metadata is journaled. Finally, data journaling is the journaling mechanism in which the metadata and data are both journaled. To clarify Hyun, et al., 2010 states that metadata refers to the data about the data. Hyun, et al., goes on to state that metadata essentially represents file creation and removal, directory creation and removal, growing a file and truncating a file.

Mechanics required for a journaling file system to operate

For a journaling file system to function adequately various prerequisites must be met. Operation requires the file system to have a specified partitioned area of the disk where it’s able to write the file data and an area to journal the data (Borislav & Timcenko, 2012). It is good practice during the creation of a file system to initialize the hard disk with a partition table to avoid any unforeseen issues that may arise (Patana-Anake, Martin, Sandler, Wu, & Gunawi, 2016). After a partition table is created one of the partitions must be selected as a primary partition which must then be formatted with the file system, which can be achieved in Linux with the mkfs.ext3 command (Patana-Anake, Martin, Sandler, Wu, & Gunawi, 2016). To make the file system more robust a label should be assigned to it, this is so the file system can eventually be mounted at boot time which makes the process more simplified and user friendly (Zhou, Huang, Li, & Wang, 2012). These are the essential mechanics required for a journaling system to function and operate.

Operations needed to create a file with the EXT3 file system

In ext3 the act of creating a new file requires a variety of sequential steps and actions to occur. File creation will require the inode (unit of storage) to change states from free to allocated, writing the data to the new file and writing metadata to a specified directory file(Hui, et al., 2011). In Ext3 data and metadata are eventually placed into standard ext2 structures, which are fixed-location structures (Piernas, Cortes, & Garcia, 2007). In this process the disk is splint into a variety of block groups (Hyun, et al., 2010). Hyun, et al., go on to say that each of these block group contain bitmaps, inode blocks and data blocks, all of which need to be updated following file creation(Hui, et al., 2011). Ext3 utilizes a journal superblock which tracks summary information for the journal, which includes block size, and the head and tail pointers of the transaction (Hui, et al., 2011). Hui, et al have stated that a journal descriptor block marks the beginning of a transaction and describes the journaled blocks that follow; which entails their eventual fixed on-disk location. In the data mode journaling mechanism the descriptor block is followed by the data and metadata blocks; in ordered and write back mode, the descriptor block is followed by the metadata blocks. Depending upon the size of the transaction, multiple descriptor blocks each followed by the corresponding data and metadata blocks may be logged (Piernas, Cortes, & Garcia, 2007). Finally, a journal commit block is written to the journal at the end of the transaction; once the commit block is written, the journaled data if ever corrupted can be recovered without loss. These are the operations which are required to create a file in the ext3 file system.

The mechanism required to update the contents of a file

Any form of updating of appending of file contents which occurs in the ext3 file system will first be written to the journal prior to being committed (Chen, Tan, Wu, & Xie, 2014). This is a write-ahead logging mechanism which enables effective crash recovery, as any incomplete operations which were going to be committed can be completed in order to bring the file system to a more consistent state (Chen, Tan, Wu, & Xie, 2014). Chen, Tan, Wu, & Xie go on to state that during normal operations, once the necessary information has been sent to its fixed specified location journal space can then be reclaimed.  Updating a file also requires several in-place writes to occur as noted by Fairbanks, Xia, & Iii, 2009. This includes the files inode to note in the file’s metadata that its size has changed. To journal an update to an inode (e.g., to update a data block pointer and file size), ext3 writes the inode’s entire enclosing block to the journal The bitmap must also then mark out an allocation of space for the updated data. Then finally the data block will be appended to the existing file, updating its contents.

How the EXT3 file system journal is utilized following an interrupted write operation

If a write operation to a storage device or disk is interrupted, any data lost can be easily recovered by utilizing the ext3 file systems journaling mechanism. Ext3 unlike in its previous versions does not write data to the disks data areas directly but rather as previously discussed, writes file data along with the files metadata to a specified area on the disk (Borislav & Timcenko, 2012). Once the data has been safely written to the journal area of the disk, it can be appended to the target file (Polte, Simsa, & Gibson, 2008). If corruption occurs due to write operation interruption recovery is possible due to the data, and metadata, essentially being written twice (once to the journal, then a second time to the disk) (Borislav & Timcenko, 2012). On the next boot up of the system the file system will be check for inconsistencies, where in remaining data will then be committed to the specified data areas of the disk to complete the updates to the target file (Chen, et al., 2017).

If the EXT3 file system has been put into is in data mode, both the data and the metadata are journaled before being committed and then copied into the data area to restore any inconsistencies (Chen, et al., 2017). Data journaling mode is the safest albeit slower of the three journaling mechanisms due to the data being written twice as noted by Polte, Simsa, & Gibson, 2008. Polte, Simsa, & Gibson  in continuation go on to state that whereas the write back and ordered modes are significantly faster however fall short in that data corruption can still occur as only the metadata is journaled and not the file data. This is in essence how the ext3 file system utilizes its journaling mechanism to restore file corruption when a write operation is interrupted.

Conclusion

In conclusion this report aimed to offer its audience a deeper insight into the operation and implementation of the third extended file system. Through the discussion of the topics discussed which included: How the ext3 file system utilizes its journaling mechanism to restore corruptions that may occur during a crash or write operation interruption, the mechanism required to update and append the contents of a file and the operations need in the creation of a file in the ext3 file system. Through the discussion of these topics hopefully the reports aim has been met and a better understanding of the ext3 file systems journaling mechanism has been achieved.

References

• Borislav, D., & Timcenko, V. (2012). The influence of disk number to the performance of striping RAID. 2012 20th Telecommunications Forum (TELFOR). doi:10.1109/telfor.2012.6419516
• Chen, J., Tan, Z., Wu, F., & Xie, C. (2014). SJournal: A New Design of Journaling for File Systems to Provide Crash Consistency. 2014 9th IEEE International Conference on Networking, Architecture, and Storage. doi:10.1109/nas.2014.15
• Chen, T., Chang, Y., Chen, S., Kuo, C., Yang, M., Wei, H., & Shih, W. (2017). Enabling Write-Reduction Strategy for Journaling File Systems over Byte-addressable NVRAM. Proceedings of the 54th Annual Design Automation Conference 2017 on – DAC 17. doi:10.1145/3061639.3062236
• Fairbanks, K. D., Xia, Y. H., & Iii, H. L. (2009). A Method for Historical Ext3 Inode to Filename Translation on Honeypots. 2009 33rd Annual IEEE International Computer Software and Applications Conference. doi:10.1109/compsac.2009.165
• Hui, S., Rui, Z., Jin, C., Lei, L., Fei, W., & Sheng, X. C. (2011). Analysis of the File System and Block IO Scheduler for SSD in Performance and Energy Consumption. 2011 IEEE Asia-Pacific Services Computing Conference. doi:10.1109/apscc.2011.29
• Hyun, C., Choi, J., Oh, Y., Lee, D., Kim, E., & Noh, S. H. (2010). A performance model and file system space allocation scheme for SSDs. 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST). doi:10.1109/msst.2010.5496986
• Kim, C., Baek, S. H., & Park, K. H. (2012). R-Barrier: Rapid Barrier for Software RAID Cache Using Hints from Journaling Filesystem. 2012 IEEE 18th International Conference on Parallel and Distributed Systems. doi:10.1109/icpads.2012.113
• Patana-Anake, T., Martin, V., Sandler, N., Wu, C., & Gunawi, H. S. (2016). Manylogs: Improved CMR/SMR disk bandwidth and faster durability with scattered logs. 2016 32nd Symposium on Mass Storage Systems and Technologies (MSST). doi:10.1109/msst.2016.7897075
• Piernas, J., Cortes, T., & Garcia, J. M. (2007). The Design of New Journaling File Systems: The DualFS Case. IEEE Transactions on Computers, 56(2), 267-281. doi:10.1109/tc.2007.36
• Polte, M., Simsa, J., & Gibson, G. (2008). Comparing performance of solid state devices and mechanical disks. 2008 3rd Petascale Data Storage Workshop. doi:10.1109/pdsw.2008.4811886
• Yeh, T., Arul, J., Wu, J., Chen, I., & Tan, K. (n.d.). Using File Grouping to Improve the Disk Performance (Extended Abstract). 2006 15th IEEE International Conference on High Performance Distributed Computing. doi:10.1109/hpdc.2006.1652186
• Zhou, K., Huang, P., Li, C., & Wang, H. (2012). An Empirical Study on the Interplay between Filesystems and SSD. 2012 IEEE Seventh International Conference on Networking, Architecture, and Storage. doi:10.1109/nas.2012.21