Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10
Phoronix: Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10
Building upon our F2FS file-system benchmarks from earlier in this week is a large comparison of four of the leading Linux file-systems at the moment: Btrfs, EXT4, XFS, and F2FS. With the four Linux kernel file-systems, each was benchmarked on the Linux 3.8, 3.9, and 3.10-rc1 kernels. The results from this large file-system comparison when backed by a solid-state drive are now published on Phoronix.
The next set of benchmarks better have btrfs told to compress with lzo, otherwise you're not really testing btrfs in a way that would be used real world.
For btrfs, are you turning off COW for database file(s) for the database-driven tests?
That would break many benchmarks. Notice that test files are often full of zeroes, yielding unrealistic benefits. Real world data isn't anything like that.
Originally Posted by Ericg
True, wasn't thinking about the fact that he just does zero-filled files instead of random-filled
Originally Posted by rvalles
Other OS tests
It would be interesting to get an idea of what that hardware can do under NTFS or OSX, for comparison. For example, btrfs looks pretty bad compared to ext4, but i wonder if it's competitive with what you'd see on other OS's. In other words, is btrfs really struggling, or is ext4 just really good?
With ZFS finally being declared stable on linux, it should really be included in these benchmarks. It is an excellent comparison for btrfs, since they are both COW, modern filesystems, which can lead to performance penalties compared to conventional filesystems like ext4 or XFS.
Btrfs has different features. But what would be worthwhile is to test NTFS (as a counterpart to EXT4) and ResFS (as a counterpart to Btrfs) on Windows.
Originally Posted by smitty3268
Michael, in 3.10, btrfs has gained skinny metadata support. It'd be interesting to benchmark btrfs with that feature turned on (needs btrfstune).
If you choose your filesystem based on a bunch of artificial benchmarks that show how "fast" it is, you are an idiot!
Choose a filesystem based on requirements and testing. If you have only the requirement for it go really fast, then sure, these could inform your decision, but you should still test with your own workloads. This is however a very specialized subset of people (pros doing video editing, photoshop artists, CERN etc.) that need outrageous speed when editing or during experiments. For long term storage these people will still be using one of the "slow" filesystems that actually protect their data.
Everyone else should pick the filesystem with the best data integrity and resiliance. You will likely never notice loss of "speed" what with continuous improvements in hardware, caching and prefetch of data.