Log in

No account? Create an account

Previous Entry | Next Entry

The purpose of the blog post is to give deserved kudos to everyone involved in the Linux filesystem stack--especially Theodore Tso--for their excellent work.

My test system is a Intel ICH10-based laptop (Lenovo ThinkPad T400) with a 100GB 7200RPM 2.5" drive.

Conversion to

I made the switch to ext4 about the same time I installed 2.6.29-rc5: some two weeks ago. The method that I chose to use to do the conversion was simple: copy everything off to a USB disk, format the rootfs and copy it back. It is possible to do an in-place conversion from ext3 to ext4 but all the existing files on the partition will not be in the new extents format. This feature decreases the metadata overhead, reduces fragmentation and massively assists in speeding up fsck. I did this in a rescue environment[0] with kernel 2.6.28, and:

# cryptsetup luksOpen /dev/sda5 sda5_crypt
# vgchange -ya
# mkdir /mnt/rootfs
# mount /dev/mapper/encrypted0-root0 /mnt/rootfs
# mkdir /mnt/backup
# mount /dev/sdb1 /mnt/backup (external ext3 formated USB HDD)
# rsync -av /mnt/rootfs/ /mnt/backup/ (SELinux people probably want -X here)
# umount /mnt/backup
# umount /mnt/rootfs
# mkfs.ext4 /dev/mapper/encrypted0-root0[1]
# mount /dev/mapper/encrypted0-root0 /mnt/rootfs
# rsync -av /mnt/rootfs/ /mnt/backup/ (SELinux people probably want -X here)
# vim /mnt/rootfs/etc/fstab (change ext3 to ext4)
# mount -t proc none /mnt/rootfs/proc
# mount -o bind /dev /mnt/rootfs/dev
# mount -t sysfs none /mnt/rootfs/sys
# mount /dev/sda3 /mnt/rootfs/boot (mounting the regular /boot partition)
# chroot /mnt/rootfs
# update-initramfs -k all -u
# exit
# umount /mnt/rootfs/boot
# umount /mnt/rootfs/sys
# umount /mnt/rootfs/dev
# umount /mnt/rootfs/proc
# umount /mnt/rootfs
# fsck.ext4 /dev/mapper/encrypted0-root0 (just for good measure, wasn't that fast!)

At this point, I was able to reboot and have a normal boot process (except faster). Note that converting your /boot partition doesn't appear to be a great idea, at the moment; grub2 should fix that soon-ish.

Subjective speed

I immediately noticed that my boot process was about twice as fast as before. However, there could be some unintended bias here[2]. Most notably, the GNOME panel appears much sooner after GDM login.

I've been through two full fsck operations after my two weeks of use, both took less than 30 seconds--down from 5 minutes before.

Most notably, fsync(FD) now flushes the file to disk, not all operations in the commit buffer. This single change makes Firefox 3 finally not suck. XFS users have had this feature for awhile, as well. I am quite happy to have my shinny new laptop behaving snappy no matter how many applications I have open. I can can have Tracker merging indexes, be running an aptitude update, and browsing in Firefox 3 without any one of these bringing the system to its knees.


Unrelated to this, I'm fighting a series of Intel Graphics stability issues while doing development on DRI2--mostly for compitor+Gnometris work. I am crashing my laptop at least once a day; usually in the form of a hard-lock.

After two weeks of this, I haven't yet lost any data or witnessed any zero-length files.

I do have a healthy backup regimen, though, to an encrypted, USB HDD.


I have--until now--managed to avoid the gritty details of how LVM and LUKS actually work. So, after many false starts, copious amounts of documentation reading and many careful attempts, I managed to succeed is a major reorganization of my laptop disk layout--without losing any data. It is possible to resize in this environment. At some point, I should write up how I did it. It's not for the faint of heart.

[0] I made my own USB-based rescue environment using Live Helper from the Debian Live project--which also rocks, incidentally. USB-based live environments boot much fast than their CD-base equivalents and don't waste a CD in the process.

[1] Debian default features are has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize

[2] The process of moving everything off and then back on is not really representative of the way file system allocations occur during a normal installation process. So, I could be loading the extents-based allocator in such a way to causes files in boot-central directories such as /bin, /sbin, /etc, and so on, to be allocated in very close proximity to each other which may not neccissarily be the case after a fresh installation. YMVV.


( 2 comments — Leave a comment )
Jun. 18th, 2009 04:13 am (UTC)
Hard lock
Hey Jason,
Thanks for this post. I'm curious about your hard lock. Are you using magic keys to sync your FS and reboot? Or are you turning off you machine without that?

Jun. 18th, 2009 04:34 pm (UTC)
Re: Hard lock
Nope, just good-ol' power-off.
( 2 comments — Leave a comment )


color, uphair, smile
Jason D. Clinton

Latest Month

September 2011


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow