Btrfs File-System For Old Computers?

Recently I published benchmarks of Btrfs from a Serial ATA 3.0 SSD (the excellent OCZ Vertex 3 SSD) and those results were interesting, but most people aren't running 6Gb/s solid-state drives, so how does this next-generation file-system perform on the opposite end of the spectrum? In this article are EXT4 and Btrfs benchmarks from an old Core Duo notebook with a 5400RPM mobile hard drive.

This testing is just like the earlier Btrfs SATA 3.0 benchmarks, but with more Btrfs mount options being tested and with old hardware being used. In particular, a Lenovo ThinkPad T60 was used with a 1.86GHz Core Duo T2400 CPU with 1GB of RAM and a Hitachi HTS541080G9SA00 HDD. The Hitachi hard drive spins at 5400RPM, complies with SATA 1.0, has 8MB of cache, and has a 12ms average seek time. Full system details are below.

An Ubuntu 11.10 development snapshot was running on this 32-bit laptop with the latest Linux 3.1 development kernel loaded at the time of testing. The EXT4 file-system was tested along with Btrfs. Between each mount option that was tested, the Btrfs file-system was re-formatted. The mount options included compress=zlib, compress=lzo, space_cache, autodefrag, nodatasum, nodatacow, and nobarrier. Below is a description of the tested Btrfs mount options from the Btrfs Wiki.

- nodatasum: Do not checksum data. Means bit flips and bit rot might go undetected, but allows for slightly faster operation since data checksum does not have to be calculated. On most modern CPUs this option does not result in any reasonable performance improvement.
- nodatacow: Do not copy-on-write data. datacow is used to ensure the user either has access to the old version of a file, or to the newer version of the file. datacow makes sure we never have partially updated files written to disk. nodatacow gives slight performance boost by directly overwriting data (like ext[234]), at the expense of potentially getting partially updated files on system failures. Performance gain is usually < 5% unless the workload is random writes to large database files, where the difference can become very large
- nobarrier: Do not use device barriers. NOTE: Using this option greatly increases the chances of you experiencing data corruption during a power failure situation. This means full file-system corruption, and not just losing or corrupting data that was being written during a power cut or kernel panic
- compress: Enable compression. In the kernels >2.6.38 you can choose the algorithm for compression:
x compress=zlib: Better compression ratio. It's the default and safe for olders kernels.
x compress=lzo: Fastest compression. btrfs-progs 0.19 or older will fail with this option. The default in the kernel 2.6.39 and newer.
- space_cache: Btrfs stores the free space data ondisk to make the caching of a block group much quicker (Kernel 2.6.37+). It's a persistent change and is safe to boot into old kernels.
- autodefrag: will detect random writes into existing files and kick off background defragging. It is well suited to bdb or sqlite databases, but not virtualization images or big databases (yet). Once the developers make sure it doesn't defrag files over and over again, they'll move this toward the default. (Kernel 3.0+)