Term Paper

On

Compare Ext2 Ext3 and Ext4

Submitted by Rajwant Kaur

Reg:11011350

Roll: RK1108A77

Introduction

What is an Ext2 file system ?

The Second Extended File System (EXT2) file system is a replacement of the Extended File System (EXT). The file system was created by Rémy Card in 1993.

EXT2 was the default file system for Linux until EXT3 came along. EXT2 still is a favored file system for Flash and USB drives due the lack of journaling. Journaling requires more writes to the storage unit and can be slow on these external devices. The Flash and USB drives have a limited number of write cycles.

The file and space limitations are as follows:

Block Size: 1KB 2KB 4KB 8KB

File size: 16 GB 256 Gigabytes 2 Terabytes 2 Terabytes
File system: 4 Terabytes 8 Terabytes 16 Terabytes 32 Terabytes

The directory and file structure is not indexed, so searching within a directory with a large amount of files can be time consuming.

EXT2 allows for a patch to be added which is an add-on (e2compr) to allow file compression. Compression is a method which compresses files on the file system to save space. Compression can also increase read speeds from the storage unit.

Files and directories are stored within Inodes.

The date ranges for timestamps can only go as high as January 18, 2038. Once this date is reached, the EXT2 file system will no longer store proper timestamps. Either other file systems must be used or a patch must be applied, if one exists.

What is an Ext3 file system ?

The EXT2 file system was extended by Stephen Tweedie in 1998 to produce the Third Extended File System (EXT3). The file system was ported into the Linux kernel, version 2.4.15, in 2001.

The EXT3 file system has the ability for an in-place upgrade from EXT2. An in-place upgrade is when one file system can be converted to another. When the conversion occurs, there is no requirement for the files to be backed up, the volume reformatted and the files restored.

The size limitations on EXT3 are as follows:

Block Size: 1KB 2KB 4KB 8KB

File size: 16 GB 256 Gigabytes 2 Terabytes 2 Terabytes
File system: 2 Terabytes 8 Terabytes 16 Terabytes 32 Terabytes

There is a 32,000 limit on the number of sub-directories within a directory. Directories are stored in a table for searching, but when indexing is enabled, the directory structure is stored in a hashed B-Tree (H-tree). Free file space is managed in a bitmap while metadata is kept in a table.

NOTE: Bitmaps are used to track used and unused space. These bitmaps are not images, but a file where each bit represents an addressable block. Each bit is either on (1) or off (0) to represent if it is used or free.

EXT3 supports Journaling and all three of its types:
Journal [writeback]
Ordered (default) [ordered]
Witeback [data]

Journaling allows a file system to recover unwritten data from an improper shutdown.

Similar to EXT2, EXT3 allows for a patch (e3compr) to be installed to enable compression.

Files and directories are stored within Inodes.

Online Resize is available to add space to the existing file system by adding more partitions to the existing file system.

Similar to EXT2, the date ranges for timestamps can only go as high as January 18, 2038. Once this date is reached, the EXT3 file system will no longer store proper timestamps. Either other file systems must be used or a patch must be applied, if one exists.

Some EXT3 file systems (depending on kernel version) can support Persistent Preallocation. In this method, space is 'reserved' or allocated for a file before it is written.

What is an Ext4 file system ?

The Fourth Extended File System (EXT4) was originally started as extensions to EXT3 to improve performance and stability. After awhile, the extensions were included as a new file system - EXT4. The stable code for EXT4 was released in Linux kernel version 2.6.28 on December 25, 2008.

EXT4 uses a 48-bit addressing system. This addressing system allows for a maximum file size of 16 Terabytes. The maximum volume size is 1 Exabyte

Directory listings are kept in an H-Tree for faster searching. The number of sub-directories within a directory is not limited.

Files stored on an EXT4 file system are stored in Extents. Extents reduce fragmentation and improve performance. Bitmaps are also used to track used and unused blocks.

Timestamps have a date limitation at April 25, 2514.

EXT4 uses Multi-Block Allocation to write multiple blocks at once instead of one block at a time to provide better performance. This method is also used with Delayed Allocation to provide better performance by flushing the cache at set time intervals instead of when data is sent to the cache.

Like EXT3, EXT4 uses a Journal. If Journaling is not needed, it can be disabled to remove file consistency ability if an improper shutdown occurs. Without the Journaling, performance is improved.

EXT4 supports Online Defragmentation by using the e4defrag tool. Fragmentation occurs more when the free drive space is low. When this occurs, disk performance can be greatly affected. Defragmenting the drive can restore slow drive performance.

EXT3 supported a default of 128 kilobyte Inodes, while EXT4 supports 256 kilobyteInodes.

EXT4 supports Persistent Preallocation. In this method, space is 'reserved' or allocated for a file before it is written.

The Second Extended File System

Motivations
The Second Extended File System has been designed and implemented to fix some problems present in the first Extended File System. Our goal was to provide a powerful filesystem, which implements Unix file semantics and offers advanced features.
Of course, we wanted to Ext2fs to have excellent performance. We also wanted to provide a very robust filesystem in order to reduce the risk of data loss in intensive use. Last, but not least, Ext2fs had to include provision for extensions to allow users to benefit from new features without reformatting their filesystem.
``Standard'' Ext2fs features
The Ext2fs supports standard Unix file types: regular files, directories, device special files and symbolic links.
Ext2fs is able to manage filesystems created on really big partitions. While the original kernel code restricted the maximal filesystem size to 2 GB, recent work in the VFS layer have raised this limit to 4 TB. Thus, it is now possible to use big disks without the need of creating many partitions.
Ext2fs provides long file names. It uses variable length directory entries. The maximal file name size is 255 characters. This limit could be extended to 1012 if needed.
Ext2fs reserves some blocks for the super user (root). Normally, 5% of the blocks are reserved. This allows the administrator to recover easily from situations where user processes fill up filesystems.
``Advanced'' Ext2fs features
In addition to the standard Unix features, Ext2fs supports some extensions which are not usually present in Unix filesystems.
File attributes allow the users to modify the kernel behavior when acting on a set of files. One can set attributes on a file or on a directory. In the later case, new files created in the directory inherit these attributes.
BSD or System V Release 4 semantics can be selected at mount time. A mount option allows the administrator to choose the file creation semantics. On a filesystem mounted with BSD semantics, files are created with the same group id as their parent directory. System V semantics are a bit more complex: if a directory has the setgid bit set, new files inherit the group id of the directory and subdirectories inherit the group id and the setgid bit; in the other case, files and subdirectories are created with the primary group id of the calling process.
BSD-like synchronous updates can be used in Ext2fs. A mount option allows the administrator to request that metadata (inodes, bitmap blocks, indirect blocks and directory blocks) be written synchronously on the disk when they are modified. This can be useful to maintain a strict metadata consistency but this leads to poor performances. Actually, this feature is not normally used, since in addition to the performance loss associated with using synchronous updates of the metadata, it can cause corruption in the user data which will not be flagged by the filesystem checker.
Ext2fs allows the administrator to choose the logical block size when creating the filesystem. Block sizes can typically be 1024, 2048 and 4096 bytes. Using big block sizes can speed up I/O since fewer I/O requests, and thus fewer disk head seeks, need to be done to access a file. On the other hand, big blocks waste more disk space: on the average, the last block allocated to a file is only half full, so as blocks get bigger, more space is wasted in the last block of each file. In addition, most of the advantages of larger block sizes are obtained by Ext2 filesystem's preallocation techniques
Ext2fs implements fast symbolic links. A fast symbolic link does not use any data block on the filesystem. The target name is not stored in a data block but in the inode itself. This policy can save some disk space (no data block needs to be allocated) and speeds up link operations (there is no need to read a data block when accessing such a link). Of course, the space available in the inode is limited so not every link can be implemented as a fast symbolic link. The maximal size of the target name in a fast symbolic link is 60 characters. We plan to extend this scheme to small files in the near future.
Ext2fs keeps track of the filesystem state. A special field in the superblock is used by the kernel code to indicate the status of the file system. When a filesystem is mounted in read/write mode, its state is set to ``Not Clean''. When it is unmounted or remounted in read-only mode, its state is reset to ``Clean''. At boot time, the filesystem checker uses this information to decide if a filesystem must be checked. The kernel code also records errors in this field. When an inconsistency is detected by the kernel code, the filesystem is marked as ``Erroneous''. The filesystem checker tests this to force the check of the filesystem regardless of its apparently clean state.
Always skipping filesystem checks may sometimes be dangerous, so Ext2fs provides two ways to force checks at regular intervals. A mount counter is maintained in the superblock. Each time the filesystem is mounted in read/write mode, this counter is incremented. When it reaches a maximal value (also recorded in the superblock), the filesystem checker forces the check even if the filesystem is ``Clean''. A last check time and a maximal check interval are also maintained in the superblock. These two fields allow the administrator to request periodical checks. When the maximal check interval has been reached, the checker ignores the filesystem state and forces a filesystem check. Ext2fs offers tools to tune the filesystem behavior. Thetune2fs program can be used to modify: • the error behavior. When an inconsistency is detected by the kernel code, the filesystem is marked as ``Erroneous'' and one of the three following actions can be done: continue normal execution, remount the filesystem in read-only mode to avoid corrupting the filesystem, make the kernel panic and reboot to run the filesystem checker. • the maximal mount count. • the maximal check interval. • the number of logical blocks reserved for the super user.
Mount options can also be used to change the kernel error behavior.
An attribute allows the users to request secure deletion on files. When such a file is deleted, random data is written in the disk blocks previously allocated to the file. This prevents malicious people from gaining access to the previous content of the file by using a disk editor.
Last, new types of files inspired from the 4.4 BSD filesystem have recently been added to Ext2fs. Immutable files can only be read: nobody can write or delete them. This can be used to protect sensitive configuration files. Append-only files can be opened in write mode but data is always appended at the end of the file. Like immutable files, they cannot be deleted or renamed. This is especially useful for log files which can only grow.

Physical Structure
The physical structure of Ext2 filesystems has been strongly influenced by the layout of the BSD filesystem [McKusick et al.1984]. A filesystem is made up of block groups. Block groups are analogous to BSD FFS's cylinder groups. However, block groups are not tied to the physical layout of the blocks on the disk, since modern drives tend to be optimized for sequential access and hide their physical geometry to the operating system.
The physical structure of a filesystem is represented in this table:
|Boot |Block |Block |...|Block |
|Sector |Group 1 |Group 2 |...|Group N |

Each block group contains a redundant copy of crucial filesystem control informations (superblock and the filesystem descriptors) and also contains a part of the filesystem (a block bitmap, an inode bitmap, a piece of the inode table, and data blocks). The structure of a block group is represented in this table:
|Super |FS |Block |Inode |Inode |Data |
|Block |descriptors |Bitmap |Bitmap |Table |Blocks |

Using block groups is a big win in terms of reliability: since the control structures are replicated in each block group, it is easy to recover from a filesystem where the superblock has been corrupted. This structure also helps to get good performances: by reducing the distance between the inode table and the data blocks, it is possible to reduce the disk head seeks during I/O on files.
In Ext2fs, directories are managed as linked lists of variable length entries. Each entry contains the inode number, the entry length, the file name and its length. By using variable length entries, it is possible to implement long file names without wasting disk space in directories. The structure of a directory entry is shown in this table:
|inode number |entry length |name length |filename |

As an example, The next table represents the structure of a directory containing three files: file1, long_file_name, and f2:
|i1 |16 |05 |file1 |

|i2 |40 |14 |long_file_name |

|i3 |12 |02 |f2 |

Performance optimizations
The Ext2fs kernel code contains many performance optimizations, which tend to improve I/O speed when reading and writing files.
Ext2fs takes advantage of the buffer cache management by performing readaheads: when a block has to be read, the kernel code requests the I/O on several contiguous blocks. This way, it tries to ensure that the next block to read will already be loaded into the buffer cache. Readaheads are normally performed during sequential reads on files and Ext2fs extends them to directory reads, either explicit reads (readdir(2) calls) or implicit ones (namei kernel directory lookup).
Ext2fs also contains many allocation optimizations. Block groups are used to cluster together related inodes and data: the kernel code always tries to allocate data blocks for a file in the same group as its inode. This is intended to reduce the disk head seeks made when the kernel reads an inode and its data blocks.
When writing data to a file, Ext2fs preallocates up to 8 adjacent blocks when allocating a new block. Preallocation hit rates are around 75% even on very full filesystems. This preallocation achieves good write performances under heavy load. It also allows contiguous blocks to be allocated to files, thus it speeds up the future sequential reads.
These two allocation optimizations produce a very good locality of: • related files through block groups • related blocks through the 8 bits clustering of block allocations.
The Ext2fs library
To allow user mode programs to manipulate the control structures of an Ext2 filesystem, the libext2fs library was developed. This library provides routines which can be used to examine and modify the data of an Ext2 filesystem, by accessing the filesystem directly through the physical device.
The Ext2fs library was designed to allow maximal code reuse through the use of software abstraction techniques. For example, several different iterators are provided. A program can simply pass in a function to ext2fs_block_interate(), which will be called for each block in an inode. Another iterator function allows an user-provided function to be called for each file in a directory.
Many of the Ext2fs utilities (mke2fs, e2fsck, tune2fs, dumpe2fs, and debugfs) use the Ext2fs library. This greatly simplifies the maintainance of these utilities, since any changes to reflect new features in the Ext2 filesystem format need only be made in one place--in the Ext2fs library. This code reuse also results in smaller binaries, since the Ext2fs library can be built as a shared library image.
Because the interfaces of the Ext2fs library are so abstract and general, new programs which require direct access to the Ext2fs filesystem can very easily be written. For example, the Ext2fs library was used during the port of the 4.4BSD dump and restore backup utilities. Very few changes were needed to adapt these tools to Linux: only a few filesystem dependent functions had to be replaced by calls to the Ext2fs library.
The Ext2fs library provides access to several classes of operations. The first class are the filesystem-oriented operations. A program can open and close a filesystem, read and write the bitmaps, and create a new filesystem on the disk. Functions are also available to manipulate the filesystem's bad blocks list.
The second class of operations affect directories. A caller of the Ext2fs library can create and expand directories, as well as add and remove directory entries. Functions are also provided to both resolve a pathname to an inode number, and to determine a pathname of an inode given its inode number.
The final class of operations are oriented around inodes. It is possible to scan the inode table, read and write inodes, and scan through all of the blocks in an inode. Allocation and deallocation routines are also available and allow user mode programs to allocate and free blocks and inodes.
The Ext2fs tools
Powerful management tools have been developed for Ext2fs. These utilities are used to create, modify, and correct any inconsistencies in Ext2 filesystems. The mke2fs program is used to initialize a partition to contain an empty Ext2 filesystem.
The tune2fs program can be used to modify the filesystem parameters. As explained in section ``Advanced'' Ext2fs features, it can change the error behavior, the maximal mount count, the maximal check interval, and the number of logical blocks reserved for the super user.
The most interesting tool is probably the filesystem checker. E2fsck is intended to repair filesystem inconsistencies after an unclean shutdown of the system. The original version of e2fsck was based on Linus Torvald's fsck program for the Minix filesystem. However, the current version of e2fsck was rewritten from scratch, using the Ext2fs library, and is much faster and can correct more filesystem inconsistencies than the original version.
The e2fsck program is designed to run as quickly as possible. Since filesystem checkers tend to be disk bound, this was done by optimizing the algorithms used by e2fsck so that filesystem structures are not repeatedly accessed from the disk. In addition, the order in which inodes and directories are checked are sorted by block number to reduce the amount of time in disk seeks. Many of these ideas were originally explored by [Bina and Emrath 1989] although they have since been further refined by the authors.
In pass 1, e2fsck iterates over all of the inodes in the filesystem and performs checks over each inode as an unconnected object in the filesystem. That is, these checks do not require any cross-checks to other filesystem objects. Examples of such checks include making sure the file mode is legal, and that all of the blocks in the inode are valid block numbers. During pass 1, bitmaps indicating which blocks and inodes are in use are compiled.
If e2fsck notices data blocks which are claimed by more than one inode, it invokes passes 1B through 1D to resolve these conflicts, either by cloning the shared blocks so that each inode has its own copy of the shared block, or by deallocating one or more of the inodes.
Pass 1 takes the longest time to execute, since all of the inodes have to be read into memory and checked. To reduce the I/O time necessary in future passes, critical filesystem information is cached in memory. The most important example of this technique is the location on disk of all of the directory blocks on the filesystem. This obviates the need to re-read the directory inodes structures during pass 2 to obtain this information.
Pass 2 checks directories as unconnected objects. Since directory entries do not span disk blocks, each directory block can be checked individually without reference to other directory blocks. This allows e2fsck to sort all of the directory blocks by block number, and check directory blocks in ascending order, thus decreasing disk seek time. The directory blocks are checked to make sure that the directory entries are valid, and contain references to inode numbers which are in use (as determined by pass 1).
For the first directory block in each directory inode, the `.' and `..' entries are checked to make sure they exist, and that the inode number for the `.' entry matches the current directory. (The inode number for the `..' entry is not checked until pass 3.)
Pass 2 also caches information concerning the parent directory in which each directory is linked. (If a directory is referenced by more than one directory, the second reference of the directory is treated as an illegal hard link, and it is removed).
It is noteworthy to note that at the end of pass 2, nearly all of the disk I/O which e2fsck needs to perform is complete. Information required by passes 3, 4 and 5 are cached in memory; hence, the remaining passes of e2fsck are largely CPU bound, and take less than 5-10% of the total running time of e2fsck.
In pass 3, the directory connectivity is checked. E2fsck traces the path of each directory back to the root, using information that was cached during pass 2. At this time, the `..' entry for each directory is also checked to make sure it is valid. Any directories which can not be traced back to the root are linked to the /lost+found directory.
In pass 4, e2fsck checks the reference counts for all inodes, by iterating over all the inodes and comparing the link counts (which were cached in pass 1) against internal counters computed during passes 2 and 3. Any undeleted files with a zero link count is also linked to the /lost+found directory during this pass.
Finally, in pass 5, e2fsck checks the validity of the filesystem summary information. It compares the block and inode bitmaps which were constructed during the previous passes against the actual bitmaps on the filesystem, and corrects the on-disk copies if necessary.
The filesystem debugger is another useful tool. Debugfs is a powerful program which can be used to examine and change the state of a filesystem. Basically, it provides an interactive interface to the Ext2fs library: commands typed by the user are translated into calls to the library routines.
Debugfs can be used to examine the internal structures of a filesystem, manually repair a corrupted filesystem, or create test cases for e2fsck. Unfortunately, this program can be dangerous if it is used by people who do not know what they are doing; it is very easy to destroy a filesystem with this tool. For this reason, debugfs opens filesytems for read-only access by default. The user must explicitly specify the -w flag in order to use debugfs to open a filesystem for read/wite access.

The Third Extended File System

Ext3, or third extended filesystem, is a journaled file system that is commonly used by the Linux kernel. It is the default file system for many popularLinux distributions, including Debian. Stephen Tweedie first revealed that he was working on extending ext2 in Journaling the Linux ext2fs Filesystem in a 1998 paper, and later in a February 1999 kernel mailing list posting. The filesystem was merged with the mainline Linux kernel in November 2001 from 2.4.15 onward. Its main advantage over ext2 is journaling, which improves reliability and eliminates the need to check the file system after an unclean shutdown. Its successor is ext4.

Performance

The performance (speed) of ext3 is less attractive than competing Linux filesystems, such as ext4,JFS, ReiserFS and XFS. But ext3 has a significant advantage in that it allows in-place upgrades from ext2 without having to back up and restore data. Benchmarks suggest that ext3 also uses less CPU power than ReiserFS and XFS. It is also considered safer than the other Linux file systems, due to its relative simplicity and wider testing base.[7][8]

ext3 adds the following features to ext2:

• A journal. • Online file system growth. • HTree indexing for larger directories
Without these features, any ext3 file system is also a valid ext2 file system. This situation 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 an fsck tool. The close relationship also makes conversion between the two file systems (both forward to ext3 and backward to ext2) straightforward.

ext3 lacks "modern" filesystem features, such as dynamic inode allocation and extents. This situation might sometimes be a disadvantage, but for recoverability, it is a significant advantage. The file system metadata is all in fixed, well-known locations, and data structures have some redundancy. In significant data corruption, ext2 or ext3 may be recoverable, while a tree-based file system may not.

Physical Structure

Size limits
The max number of blocks for ext3 is 232. The size of a block can vary, affecting the max number of files and the max size of the file system:[10]

|Block size |Maximum |Maximum |
| |file size |file system size |
|1 KiB |16 GiB |2 TiB |
|2 KiB |256 GiB |8 TiB |
|4 KiB |2 TiB |16 TiB |
|8 KiB[limits 1] |2 TiB |32 TiB |

1. Jump up^ In Linux, 8 KiB block size is only available on architectures which allow 8 KiB pages, such asAlpha.
Journaling levels
There are three levels of journaling available in the Linux implementation of ext3:

Journal (lowest risk) Both metadata and file contents are written to the journal before being committed to the main file system. Because the journal is relatively continuous on disk, this can improve performance, if the journal has enough space. In other cases, performance gets worse, because the data must be written twice—once to the journal, and once to the main part of the filesystem. Ordered (medium risk) Only metadata is journaled; file contents are not, but it's guaranteed that file contents are written to disk before associated metadata is marked as committed in the journal. This is the default on many Linux distributions. If there is a power outage or kernel panic while a file is being written or appended to, the journal will indicate that the new file or appended data has not been "committed", so it will be purged by the cleanup process. (Thus appends and new files have the same level of integrity protection as the "journaled" level.) However, files beingoverwritten can be corrupted because the original version of the file is not stored. Thus it's possible to end up with a file in an intermediate state between new and old, without enough information to restore either one or the other (the new data never made it to disk completely, and the old data is not stored anywhere). Even worse, the intermediate state might intersperse old and new data, because the order of the write is left up to the disk's hardware. XFS uses this form of journaling.

Writeback (highest risk) Only metadata is journaled; file contents are not. The contents might be written before or after the journal is updated. As a result, files modified right before a crash can become corrupted. For example, a file being appended to may be marked in the journal as being larger than it actually is, causing garbage at the end. Older versions of files could also appear unexpectedly after a journal recovery. The lack of synchronization between data and journal is faster in many cases. JFS uses this level of journaling, but ensures that any "garbage" due to unwritten data is zeroed out on reboot. In all three modes, the internal structure of file system is assured to be consistent even after a crash. In any case, only the data content of files or directories which were being modified when the system crashed will be affected; the rest will be intact after recovery.

The Fourth Extended File System

Ext4 is an advanced level of the ext3 filesystem which incorporates scalability and reliability enhancements for supporting large filesystems
(64 bit) in keeping with increasing disk capacities and state-of-the-art feature requirements.

Features

• ability to use filesystems > 16TB (e2fsprogs support not available yet) • extent format reduces metadata overhead (RAM, IO for access, transactions) • extent format more robust in face of on-disk corruption due to magics, • internal redundancy in tree • improved file allocation (multi-block alloc) • lift 32000 subdirectory limit imposed by i_links_count[1] • nsec timestamps for mtime, atime, ctime, create time • inode version field on disk (NFSv4, Lustre) • reduced e2fsck time via uninit_bg feature • journal checksumming for robustness, performance • persistent file preallocation (e.g for streaming media, databases) • ability to pack bitmaps and inode tables into larger virtual groups via the • flex_bg feature • large file support • Inode allocation using large virtual block groups via flex_bg • delayed allocation • large block (up to pagesize) support

The Final Verdict

For hard disk drives, removable USB drives and other media used by Linux, the most common file systems you’ll find are ext2, ext3 and ext4. As the names imply, these are the second, third and fourth iterations of the extended file system, which was originally developed in 1992. The first version of extended file system is essentially obsolete. But the current three extended file systems are still widely used. Read on for a comparison of all three.

Ext2 File System

The ext2 file system (second extended file system) as designed as a replacement to the original extended file system. Among other limitations, ext2 remedied issues with ext including fragmentation and immutability of inodes. When comparing ext2 to ext3 and ext4, the main differentiator is that ext2 is not a journaled file system. The maximum file size for an individual file size on an ext2-formatted volume depends on the block size chosen. If a 1 KB block size is chosen, then the max individual file size is 16 GB. You can choose block sizes up to 8 KB, which yields a 32 TB max individual file size. The maximum file system size is between 4 TB and 32 TB, again, based on the block size.

If ext2 has any advantage over ext3 and ext4, it’s that it doesn’t include the overhead and extra write processes involved with journaling. Theoretically, ext2 should be faster than ext3. Furthermore, some argue that the additional write commands will result in increased “wear and tear” on the card or drive. This is important for flash drives, which have a more limited longevity per sector. However, whether or not the benefits in speed and long term reliability is noticeable isn’t clear.

Ext3 File System

In terms of file system and individual file sizes, ext3 is the same as ext2. It has individual file sizes between 16 GB and 32 TB based on block size and filesystem sizes between 4 TB and 32 TB. But the big difference is that it is a journaled file system. This allows it to be more robust in preventing file corruption, particularly when write processes are interrupted unexpectedly (e.g. removing a thumbdrive before safely ejecting, powering off or crashing suddenly, power outages, etc.).

Ext4 File System

Ext4 is the fourth extended file system and it is an improvement upon the ext3 file system. In addition to journaling, ext4 file systems support even larger file sizes and file system sizes. Individual max file sizes on an ext4 file system range from 16 GB to 16 TB. The max file system size is 1 exabyte. An exabyte, in case you’ve not come across this enormous unit size, is 1,000,000 terabytes. Ext4 also introduces some more reliability features, including delayed allocation, journal checksum, fast fsck and multiblock allocation.

With ext4, you can also turn off the journaling function, essentially giving you the benefits of ext2 without sacrificing the other improvements of ext3 and ext4.

Upgrading Ext File Systems

One of the perks of ext file systems is that you can move among them without doing a backup/restore. For example, you can convert an ext2 to ext3 without affecting any of the data on the file systems. You can also mount an ext3 file system as an ext4 volume and see all the benefits of ext4 on an ext3 formatted drive. You can do the same with ext2, provided that you are running a Linux kernel 2.6.28 or later.