Convert a software raid volume from ext3 to ext4 (or ext2)?

The differences between the various and sundry ext[0-9] filesystems are more about features, and less about structure. The advantage is that they are fairly compatible with each other. For instance, you can mount an ext3 partition as ext2 and everything should work just fine. Similarly, you can mount an ext3 partition as ext4. Whenever you do either of these operations, you won't have access to the version specific features. For instance, if you mount an ext3 partition as ext2 you will lose access to the journal. Similarly, mounting an ext3 partition as ext4 won't let you use the newer features such as decreased fsck times and extents rather than bitmaps.

In order to make the conversion what you'll need to do, at a high level, is

1. unmount the partition
2. run the conversion
3. mount the partition

So as long as this is not your primary disk you can do this without having to take down the system, you just have to expect the target partition to be down for some length of time. And, as always, before fiddling around with your filesystem you should take a full backup of the data on the off-chance you have some loss.

The exact commands you should run to do this are as followed. For my purpose, I'm going to assume your target device is /dev/md0

umount /dev/md0
fsck.ext3 -pf /dev/md0
tune2fs -O extents,uninit_bg,dir_index /dev/md0
fsck.ext4 -yfD /dev/md0

The first fsck is to make sure that your filesystem is in a clean and sane state before we do the conversion. Otherwise the process may fail, or even worse, may succeed but leave inconsistencies laying around. The tune2fs command is for fiddling with the filesystem settings. It was originally created for ext2, hence the '2fs' part of the name, however it is used for modifying all versions of the ext filesystem. In this case we are enabling the extra features that were added between ext3 and ext4. The final fsck is doing two things. First it makes sure that any necessary cleanup from the conversion happens, and secondly it will create, or rebuild, the directory index.

After all this you will need to edit the /etc/fstab to make sure it is mounted as ext4, though in truth the auto option should correctly identify it as such.

Congratulations, so long as nothing caught fire/blew up/committed mass genocide/convicted of murdering it's wife during the process then you should be the happy owner of an ext4 partition.

Yes, converting to ext4 should give you better performance, for reasons like delayed allocation. ext4 is also better at preventing file fragmentation, which also helps performance. Moreover, there's a serious talk about handling of ext3 filesystems by ext4 module, so very probably you are going to use the same code Pretty Soon Now(TM) even if you stay at ext3.

Going to ext2 is a bad idea. You'd move to an old code, without all the improvements your hard-working file system developers put into ext3 and ext4 over a decade or so (ext3 was introduced in fall of 2001).

How do you convert? There are 2 approaches:

1. Convert in-place. You've found the correct procedure and Scott Pack also gave it in his answer.
2. Backup, create an ext4 from scratch and restore.

Frist one is much less hassle, but you don't get some of the benefits of ext4 for files already present in the filesystem (i.e. they won't be extent-based).

Backup-mkfs-restore will give you all features for all files, and mkfs.ext4 will make sure that alignment of data is playing well with your underlying software RAID. If you got the alignment right when creating ext3 filesystem, then there will be no gain. If you made a mistake, potentially you can gain a lot.

Which method to choose? Up to you. If your filesystem works fine now, and you just want to run current file system, you can convert in-place. If you experience performance problems and hope that filesystem change will help you with these, I'd go for a method 2.

ext3 is basically ext2 + a journal. Maintaining the journal adds a certain amount of overhead to regular operation (depending on the journaling option set), but improves filesystem reliability and reduces fsck times after a system crash or power outage. For rapidly changing transient data and/or rarely changing data (or for systems with battery backup and/or willingness to wait for fsck to complete once the power is back on), the difference in speed can be significant.

Changing ext3 to ext2 is simply a matter of changing the filesystem type to ext2 and rebooting. You'll have warnings about mounting ext3 filesystems as ext2, but you can make these go away by disabling the journal and forcing a fsck: tune2fs -O ^has_journal /dev/whatever

ext4 is basically ext3 + a lot of new features. Chief among those are extents which replace the old "block maps" of yore with contiguous memory allocations, reducing fragmentation and increasing linear read performance, especially for large files. Further, ext3 options like directory indexes are on by default.

Conversion to ext4 can be done on the fly by ensuring that your system properly supports ext4, then using a current version of tune2fs to enable the various ext4 options, changing the filesystem type to ext4 and rebooting, however this conversion method won't convert any of the existing files to use extents. For the full benefit of ext4, it would be best to back up everything, reformat and restore.

Whichever direction you go, benchmarks support your idea that you can do better than ext3.