ProductsDesktop Server Red Hat Enterprise Linux OpenStack Platform For IBM POWER For IBM System z For SAP Business Applications Red Hat Satellite Management For Scientific ComputingExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportAccelerate Automate Integrate Red Hat JBoss Developer Studio Portfolio Edition Web Framework Kit Application Platform Web Server Data Grid Portal Fuse Red Hat JBoss A-MQ SOA Platform BRMS Data Services Platform JBoss Operations Network JBoss Community or JBoss enterprise
SolutionsWhy Red Hat Why open hybrid cloud? The new IT Public cloud Cloud resource library Private cloud Infrastructure-as-a-Service (IaaS) Platform-as-a-Service (PaaS) Cloud applications and workloadsSolaris to Red Hat Enterprise Linux Migration overview Migrate from your UNIX platform How to migrate to Red Hat Enterprise Linux Upgrade to the latest Red Hat Enterprise Linux release JBoss Enterprise Middleware Benefits of migrating to Red Hat Enterprise Linux Migration services Start a conversation with Red Hat
TrainingClassroom training Red Hat Online Learning Virtual training Remote classroom training On-site team training Online Learning LabsPopular and new courses Red Hat JBoss Administration curriculum Core System Administration curriculum Red Hat JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing, Virtualization, and Storage curriculum
ConsultingSOA and integration Business process management Cloud and Virtualization Custom Software Development Enterprise Data and Storage Systems management Migrations
Table of contents
Why do you want to migrate from ext2 to ext3? Four main reasons: availability, data integrity, speed, and easy transition.
After an unclean system shutdown (unexpected power failure, system crash), each ext2 file system cannot be mounted until its consistency has been checked by the e2fsck program. The amount of time that the e2fsck program takes is determined primarily by the size of the file system, and for today's relatively large (many tens of gigabytes) file systems, this takes a long time. Also, the more files you have on the file system, the longer the consistency check takes. File systems that are several hundreds of gigabytes in size may take an hour or more to check. This severely limits availability.
By contrast, ext3 does not require a file system check, even after an unclean system shutdown, except for certain rare hardware failure cases (e.g. hard drive failures). This is because the data is written to disk in such a way that the file system is always consistent. The time to recover an ext3 file system after an unclean system shutdown does not depend on the size of the file system or the number of files; rather, it depends on the size of the "journal" used to maintain consistency. The default journal size takes about a second to recover (depending on the speed of the hardware).
Using the ext3 file system can provide stronger guarantees about data integrity in case of an unclean system shutdown. You choose the type and level of protection that your data receives. You can choose to keep the file system consistent, but allow for damage to data on the file system in the case of unclean system shutdown; this can give a modest speed up under some but not all circumstances. Alternatively, you can choose to ensure that the data is consistent with the state of the file system; this means that you will never see garbage data in recently-written files after a crash. The safe choice, keeping the data consistent with the state of the file system, is the default.
Despite writing some data more than once, ext3 is often faster (higher throughput) than ext2 because ext3's journaling optimizes hard drive head motion. You can choose from three journaling modes to optimize speed, optionally choosing to trade off some data integrity.
- One mode, data=writeback, limits the data integrity guarantees, allowing old data to show up in files after a crash, for a potential increase in speed under some circumstances. (This mode, which is the default journaling mode for most journaling file systems, essentially provides the more limited data integrity guarantees of the ext2 file system and merely avoids the long file system check at boot time.)
- The second mode, data=ordered (the default mode), guarantees that the data is consistent with the file system; recently-written files will never show up with garbage contents after a crash.
- The last mode, data=journal, requires a larger journal for reasonable speed in most cases and therefore takes longer to recover in case of unclean shutdown, but is sometimes faster for certain database operations.
The default mode is recommended for general-purpose computing needs. To change the mode, add the data=
It is easy to change from ext2 to ext3 and gain the benefits of a robust journaling file system, without reformatting. That's right, there is no need to do a long, tedious, and error-prone backup-reformat-restore operation in order to experience the advantages of ext3. There are two ways to perform the transition:
- The Red Hat Linux installation program offers to transition your file systems when you upgrade your system. All you have to do is select one checkbox per file system.
- The tune2fs program can add a journal to an existing ext2 file system. If the file system is already mounted while it is being transitioned, the journal will be visible as the file .journal in the root directory of the file system. If the file system is not mounted, the journal will be hidden and will not appear in the file system. Just run tune2fs -j /dev/hda1 (or whatever device holds the file system you are transitioning) and change ext2 to ext3 on the matching lines in /etc/fstab. If you are transitioning your root file system, you will have to use an initrd to boot. Run the mkinitrd program as described in the manual and make sure that your LILO or GRUB configuration loads the initrd. (If you fail to make that change, the system will still boot, but the root file system will be mounted as ext2 instead of ext3 you can tell this by looking at the output of the command cat /proc/mounts.) More information on tune2fs can be found in the tune2fs man page (man tune2fs).