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.
The truly paranoid sysop will
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.
touch /forcefsck
Your distro should include the module 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.
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.
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.
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 kernelline(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
.
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.
Edit /etc/fstab
replacing ext2 with ext3 for each filesystem
that was converted in the previous step.
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,
and reboot at your
convenience. I've never had a problem in the ensuing fsck, but...
touch /forcefsck