BTRFS is effectively stable
By joe
- 2 minutes read - 310 wordsYeah, I know, the web page says its under heavy development. And its on disk format can change. And its mailing list is chock full of patches. But it passed our stability test. 100 iterations (3.2TB written/read in all and compared to checksums) of the following fio test case.
[global]
size=8g
iodepth=32
blocksize=1m
numjobs=4
nrfiles=1
ioengine=vsync
rw=write
[sw1]
create_serialize=0
create_on_open=1
#directory=/data
directory=/mnt/btrfs
verify=crc32c-intel
verify_async=8
group_reporting
This is our baseline test. Failing RAIDs, failing drives, failing SSDs tend not to pass this test. Borked file systems tend not to pass this test. When something passes this test, again and again (3rd time we’ve run it), and does so without fail, we call it safe. This said, its not terribly fast on reads/writes. This is a 2.6.36 kernel. We are still working out the kinks, and trying to understand IO with this kernel. So far I like it, and we may start very serious testing with this series (though lots of good patches appear to be scheduled for the .37 and .38 time frame). I’ve not been too happy with .35, as IO performance is about 1/2 of what it should be (same tests on same box/hardware/disks/file system running 2.6.32.22.scalable) BTRFS is stable enough now for use. It just won’t (yet) win benchmarks (not counting the stuff at Phoronix and others) [update] some have complained about this (see the bits in the comments below). There are valid points to their complaints … there are real issues remaining with it. You can use it for storing data and retrieving it. But be aware of the fill issues, the current lack of a repair tool. This said, all of those are solvable issues. I am not concerned by these. Do I suggest wide spread use? Not until we have those repair tools, and some of the major issues with the fill crash are solved.