How to Convert an ext2 Filesystem to ext3

James F. Carter, 2005-01-06

On the web I've seen a number of questions from sysops who have tried to convert their filesystems to ext3 and had trouble. Here's a summary of what I've learned about this process when doing it on my own machines. The configuration file names are for the SuSE Linux 9.2 distro, but it should be fairly easy to find the equivalent functions on other distros.

Remember that with ext3 you will never notice an unclean unmount and run fsck. This is good and bad. Good is, you can get your server or laptop back in operation without having to wait through a long fsck, and the journal feature almost always keeps the filesystem in a self-consistent state, even if the last few hundred bytes of data don't make it to the disc. Bad is, if the filesystem becomes corrupt despite the journal feature, you won't know. After a machine crashes, it's a good idea to reboot and force fsck to run as soon as possible consistent with service goals. Remember that the fsck runs a lot faster than restoring a whole filesystem from tape, if you run with corruption for days on end, and the filesystem gets totally horked.

  1. The truly paranoid sysop will touch /forcefsck and reboot before doing any of this, so it is certain that any filesystem corruption is detected and fixed, and is not blamed incorrectly on the ext3 conversion.

  2. Your distro should include the module ext3.ko. If you're using a self-compiled kernel and you don't have the module (and didn't hardwire ext3 support into the kernel), reconfigure your kernel and select ext3 under filesystems, and rebuild it. My inclination is to compile the module, but others may prefer to link it directly into the kernel and to bypass the initrd.

  3. In /etc/sysconfig/kernel, add "ext3" to INITRD_MODULES. You might list jbd, but it is a dependency and will be included automatically. Make sure that the RAID driver is also listed, if needed.

  4. To make the initrd, execute mkinitrd. Verify that the needed modules were loaded. On a RAID system these would be (e.g.) jbd.ko ext3.ko scsi_mod.ko sr_mod.ko megaraid.ko. Without the initrd, there will be a message at boot time to the effect of mounting ext3 filesystem as ext2, referring to the root, because the ext3 module can't be loaded until after the root is mounted, if it's left out of the initrd.

  5. Is the initrd actually being used? If formerly you had no modular filesystems, SCSI, RAID, etc., then there would have been no need for an initrd. You need a line like

    initrd (hd0,0)/boot/initrd
    after the kernel line(s) in /boot/grub/menu.lst. Change (hd0,0) to the boot device that the file is actually on; but on 99% of machines it ends up as (hd0,0). If you're still using LILO, translate the syntax appropriately, and re-execute LILO after rebuilding the initrd and/or modifying /etc/lilo.conf.

  6. On each filesystem to be converted (normally, all the ext2 filesystems), do:

    tune2fs -c 0 -i 30 -j /dev/hda1
    substituting in turn each affected device. You can do this safely with the device mounted.

    Adjust -c and -i according to local policy: -c means check every N mounts; 0 disables it, and it's kind of irrelevant in a datacenter environment. -i means check every N days, here, at the next reboot if 30 days have gone by. One or the other of these should be positive; otherwise fsck will never get run.

  7. Edit /etc/fstab replacing ext2 with ext3 for each filesystem that was converted in the previous step.

  8. The change takes effect at the next reboot. For the maximum in paranoia, it's a good idea to boot with the -b switch and manually run fsck on each device, while the root is still mounted readonly. As a more automated alternative, touch /forcefsck and reboot at your convenience. I've never had a problem in the ensuing fsck, but...