Whatever the preferred pronunciation might be, the 64-bit Btrfs file system is now in its second year as a stable release since 2013.
Btrfs features a number of file system improvements to ensure the reliability of data. While it might not be as heavy-duty as the older but more industrial ZFS introduced in 2005, Btrfs gives Linux users a chance to use modern file system features comparable to ZFS without becoming entangled in the legalese that ZFS tends to bring.
But how does Btrfs compare to the existing ext4 on an everyday desktop system? Will file transfers be faster or slower with Btrfs?
This article is a short comparison between ext4 and Btrfs using a dedicated 7200 RPM hard drive for Btrfs testing in a desktop computer. The only purpose is to time a few file transfers, not to compare all aspects of both file systems to each other.
Is there a difference in transfer rates between ext4 and Btrfs? No online review provided a satisfactory answer. Some results reported that Btrfs was too slow, and others reported that Btrfs screamed past ext4 and xfs.
“How would Btrfs perform for me?” So, I performed my own tests using everyday hard drives and hardware.
An everyday computer running Linux Mint 17.1 was used for testing. Nothing server-class or high-end like SCSI. I used a dedicated Seagate 320 GB SATA 7200 RPM hard drive that has provided reliable use for the past few years. I already knew how it should perform.
Two types of tests were performed: File transfers involving files of three different sizes, and a raw read benchmark using hdparm. In practice, at least for me, these tests usually indicate what to expect from the file system during normal usage when copying files.
All tests were performed from the command line using the time command to time the transfer. The real result from time showed how long each transfer took. Each test was performed three times in a row, and then the results were averaged.
The 320 GB hard drive was formatted as ext4 or Btrfs using GParted. Real hardware was used, not virtual devices.
Note: Linux Mint 17.1 requires that btrfs-tools be installed before a Btrfs file system can be formatted.
Small File Test:
- 1.8 GB file of typical random data, such as a ZIP file.
- 1.0 GB file of synthetic random data created using the dd command with /dev/urandom as the source. This was to ensure that no compression was possible on the raw data.
Large File Test:
- A 24 GB file of random, compressed data.
Raw Read Benchmark:
hdparm -Tt on the device.
Which is faster? Honestly, the results are so close that it makes little difference. While the times reveal Btrfs slightly slower, unless timed, I could not tell from everyday usage. For example, a 24 GB file took the same apparent time to transfer using both ext4 and Btrfs.
The chart does need some explaining.
The 1.0 GB test was puzzling. Even though the the 1.8 GB test took about 5-6s to complete, the 1 GB file transfer finished almost instantly. This is not logical. It should take at least 2-3s to complete, so I suspect caching somewhere. Nonetheless, this what time consistently reported.
All transfers were ext4 to ext4 or ext4 to Btrfs. Nothing was pure Btrfs to Btrfs because this reflects how I would actually use a computer. Transferring data between different file systems is common, such as FAT32 to ext4, so I wanted to test the transfer rate between Btrfs and ext4 the most.
I performed tests using a solid state drive (SSD) to see if that would make any difference. It did not. From these tests, an SSD and a 7200 RPM drive offered practically the same transfer rate. I suspect that this is because the 7200 RPM is the bottleneck. A file transfer can only be as fast as the slowest drive (assuming no impediments elsewhere).
hdparm measures the raw read performance of a hard drive, so this is not an accurate measure of a file system’s performance. However, I still wanted to see if the file system would have an effect on hdparm’s read results. It was the same for both file systems.
When copying the 24 GB file from the 7200 Btfs drive to an SSD, Btrfs was faster than ext4.
Which to use: ext4 or Btrfs? For now, ext4 is the winner despite identical performance. Why? Convenience and ubiquity. Ext4 is still an excellent file system for desktop/workstation use. Ext4 is provided by default, so you can install an operating system on it. In addition, ext4 supports volumes up to 1 EB (exabyte) and files up to 16 TB in size, so there is still plenty of room for growth where space is concerned.
Btrfs might offer greater volumes (up to 16 EB) and improved fault tolerance, but, at the moment, it feels more like an add-on file system rather than one integrated into Linux. For example, btrfs-tools must be present before a drive can be formatted with Btrfs. This means Btrfs is not an option during Linux installation, though this might vary with the distribution.
Even though transfer rates are important (Who wants to wait for files to copy?), there is more to a file system than the speed of file transfers. Btrfs has many good features. Copy-on-Write, snapshots, extensive checksums, scrubbing, deduplication, self-healing data, and many more useful improvements ensure data integrity. Btrfs lacks the RAID-Z features of ZFS, so RAID is still in the experimental state with Btrfs. However, for pure data storage, Btrfs is the winner over ext4, but time will tell.
For now, ext4 seems to be the better choice on a desktop system since it is already present as a default file system, and it is slightly faster than Btrfs when transferring files. But keep in mind that this is a single drive on a desktop system. Data farms and large storage pools might reveal a different story and show the true differences between ext4 and Btrfs.
Btrfs is definitely worth looking into, but a complete switch to replace ext4 on desktop Linux might be a few years away.