Convert ROOT ‘/’ ext3 to ext4 on Ubuntu Karmic

June 26th, 2009 | Tags: , , , , , ,

After some difficulties with development ubuntu UNR 9.10 Karmic Koala distribution and its (then) kernel, I finally got a stable system on my HP2133 netbook when I upgraded the kernel to All problems with system freezes and wireless (b43fwcutter) were solved and the system has been running perfect for the last days.

So now I’ve decided to change my root file system to the new ext4.

Before gaining the system stability I run multiple installations and tried ext4 and run fine and speedy on the system, so there should be no problem on conversion. I’ve read that migrated file systems do not run as speedy as if you do an ext4 clean install, because old files are not converted to extents format, only the new one. But I expect that performance increase will be gained on the following upgrades done on most used system packages and files.

WARNING: Once you run following commands, the files ystem will no longer be mountable using the ext3. Please note that ext4 may have some bugs so do not use for production servers (wait for sometime watch Linux kernel mailing list for ext4 bugs). It’s recommended that you keep /boot in a ext3 partition for sometime.

WARNING: Remember that your kernel must support ext4 (2.6.28+), and also your GRUB.

WARNING: Next steps are based on Ubuntu UNR 9.10 Karmic Koala, kernel, e2fsck 1.41.5 and GRUB 1.96

1) First step, if you have multiple partitions and/or disks, is knowing where the ROOT is, so run mount and check the mount point for ‘/’:

$ mount
/dev/sda4 on / type ext3 (rw,relatime,errors=remount-ro,commit=600)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/bitfmt_misc type bitfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/esbiete/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=esbiete)
/dev/sdb on /media/cdrom0 type vfat (rw,uid=100,utf8,dmask=027,fmask=137)

2) So in my case ‘/’ is located on /dev/sda4. Next you can run tune2fs to convert the file system:

$ sudo tune2fs -O extents,uninit_bg,dir_index /dev/sda4

3) If there are no errors, file system will be quickly converted, but there will always be some inconsistencies that must be corrected before any other action. So cd to ‘/’ and run e2fsck:

$ cd /
$ sudo e2fsck -fpDC0 /dev/sda4

After saying ‘y’ to the warning your file system will be checked an inconsistencies repaired.

4) Also do not forget that you have to update /etc/fstab file so it can mount ext4 file system.

5) Last step is rebuilding your GRUB2 startup configuration (not really necessary, but preferably after any change related to FS):

$ cd /boot/grub
$ sudo cp grub.cfg grub.cfg.old
$ sudo grub-mkconfig -o grub.cfg

I forgot step number 4 and, after reboot, the system run an automated fsck that can not be concluded, as it encountered an UNEXPECTED INCONSISTENCY, and asked to perform a manual fsck:

$ e2fsck -fvDC0 /dev/sda4

It found some unattached inodes that were connected to /lost+found and fixed. Also some wrong block counts, inode bitmap differences and wrong directories count. All fixed. Press CTRL+D to reboot and let the startup process to perform a last fsck. The file system was back to ext3. So I repeated all steps and it converted successfully.

Enjoy your new ext4 system.

  1. July 7th, 2009 at 01:17
    Reply | Quote | #1

    Hi. I like the way you write. Will you post some more articles?

  2. savvas
    July 9th, 2009 at 15:46
    Reply | Quote | #2

    Why everyone recommends only “extents,uninit_bg,dir_index” while in /etc/mke2fs.conf it mentions:

    ext4 = {
    features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
    inode_size = 256

  3. July 10th, 2009 at 20:53
    Reply | Quote | #3

    savvas, I can not answer you with a really detailed explanation, as my post was describing my experience, and not the technical background about ext4, which I honestly do not know.

    Any way I’ve done some research and found that the commonly mentioned options are the ones you would usually need, apart from being the most used, debugged and developed. These options are also performance wins .

    But about the not mentioned features I’ve found some information on the mke2fs man page, that may be you may be able to complete with your own experience:

    ‘huge_file’ : support for 2TB or larger files.
    ‘extra_isize’ : related to huge_file (I think)
    ‘has_journal’ : Create an ext3 journal (as if using the -j option. You are able to use ext4 without journaling (kernel has to support it, +2.6.29)
    ‘flex_bg’ : Allow bitmaps and inode tables for a block group to be placed anywhere on the storage media (use with -G option to group meta-data in order to create a large virtual block group).
    ‘uninit_bg’ : Create a filesystem without initializing all of the block groups. This feature also enables checksums and highest-inode-used statistics in each block-group. This feature can speed up filesystem creation time noticeably (if lazy_itable_init is enabled), and can also reduce e2fsck time dramatically. It is only supported by the ext4 filesystem in recent Linux kernels.
    ‘dir_nlink’ : no information

    Want to note that some of the features were not completed until recent e2fsprogs release.

    Of course, each one has to choose the features based on his/her needs.

    Please, complete with your comments, as mentioned before, I’m not an expert (in fact, I’m far from being one ;)). More information can be found at