Information AboutExt3 |
| CATEGORIES ABOUT EXT3 | |
| disk file systems | |
The ext3 or '''third extended filesystem''' is a Journalled File System that is commonly used by the Linux Operating System . It is the default File System for many popular Linux Distributions . Stephen Tweedie first revealed that he was working on extending Ext2 in a February 1999 kernel mailing list posting1 and the filesystem was merged with the mainline kernel from 2.4.15 onward.2 ADVANTAGES Although its performance (speed) and security is less attractive than competitors such as and XFS . The ext3 file system adds, over its predecessor:
Without these, any ext3 file system is also a valid ext2 file system. This has allowed well-tested and mature file system maintenance utilities for maintaining and repairing ext2 file systems to also be used with ext3 without major changes. The ext2 and ext3 file systems share the same standard set of utilities, E2fsprogs , which includes a Fsck tool. The close relationship also makes conversion between the two file systems (both forward to ext3 and backward to Ext2 ) straightforward. There are three levels of journaling available in the Linux implementation of ext3: ; Journal : (slow, but least risky) Both metadata and file contents are written to the journal before being committed to the main filesystem. This improves reliability at a performance penalty because all data has to be written twice. Without this setting in /etc/fstab, a file being edited in-place during a power outage or kernel panic risks being corrupted, depending on how the application is writing to the file. ; Ordered : (medium speed, medium risk) Ordered is as with ''writeback'', but forces file contents to be written before its associated metadata is marked as committed in the journal. This is the default on many Linux distributions. ; Writeback : (fastest, most risky; equivalent to ext2 in some sense) Here metadata is journaled but file contents are not. This is faster, but introduces the hazard of out-of-order writes where, for example, files being appended to during a crash may gain a tail of garbage on the next mount. While in some contexts the lack of "modern" filesystem features such as dynamic inode allocation and tree-based data structures could be considered a disadvantage, in terms of recoverability this gives ext3 a significant advantage over filesystems with those features. The filesystem metadata is all in fixed, well-known locations, and there is some redundancy inherent in the data structures that may allow ext2 and ext3 to be recoverable in the face of significant data corruption, where tree-based filesystems may not be recoverable. DISADVANTAGES Functionality Since ext3 aims at being mostly compatible with ext2, many of the on-disk structures are similar to those of ext2. Because of that, ext3 lacks a number of features of more recent designs, such as dynamic allocation of i-nodes and variable block sizes (frags or tails). ext3 filesystems cannot be Fsck ed while the filesystem is mounted for writing. A dump of the filesystem taken while it is mounted read-write may result in corrupt data within the dump file. ext3 does not support Extent s, a feature found in other filesystems such as JFS2 and Ext4 . Defragmentation There is no online ext3 Defragmentation tool working on the filesystem level. An offline ext2 defragmenter, e2defrag, exists but requires that the ext3 filesystem be converted back to ext2 first.But depending on the feature bits turned on on the filesystem, e2defrag may destroy data; it does not know how to treat many of the newer ext3 features.3There are userspace defragmentation tools like Shake and defrag[http://ck.kolivas.org/apps/defrag/ , which work by copying each file and hoping the newly allocated file was not fragmented. However this only works if the filesystem is reasonably empty, and such filesystems are not usually fragmented. A true defragmentation tool does not exist for ext3 [http://www.redhat.com/archives/ext3-users/2005-March/msg00013.html]. Undeletion Unlike ext2, ext3 zeroes out block pointers in the Inode s of deleted files. It does this to simplify read-write access to the filesystem when the journal is being replayed after an unclean mount. This, however, effectively prevents files from being undeleted. The user's only recourse is to Grep the hard drive for data known to signal the start and end of the file. This provides slightly more secure deletion than ext2, which can be either an advantage or a disadvantage. Compression Support for transparent Compression (available as an unofficial patch for ext2) is not available in ext3. Size limits ext3 has a relatively small maximum size for both individual files and the entire filesystem. These limits are dependent on the block size of the filesystem; the following chart summarizes the limits4: The 8 KiB block size is only available on architectures (such as Alpha ) which allow 8 KiB Page s. No checksumming in journal Ext3 does not do Checksum ming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.http://archives.free.net.ph/message/20070518.134838.52e26369.en.htmlhttp://archives.free.net.ph/message/20070519.014256.ac3a2e07.en.html (This option is not enabled by default on almost all popular Linux distributions, and thus most distributions are at risk.) Consider the following scenario: If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to Amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or kernel panic should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the "winners" (transactions with a commit block, including the invalid transaction above which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. ''The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal.'' If checksums had been used (if the blocks of the "fake winner" transaction were tagged with mutual checksum), the file system could have known better and not replayed the corrupt data onto the disk. As of June 24, 2007, a patch is in the works to fix this problem. EXT4DEV / EXT4 See Also: ext4 An enhanced version of the filesystem was released on October 10 , 2006 under the name of Ext4 . It includes many new features. NOTES AND REFERENCES SEE ALSO EXTERNAL LINKS
|
|
|