Btrfs In Linux 3.4 Kernel Has Big Changes

[jwilliams]

Does it have a fsck yet?

There is some code for btrfsck in a "dangerdonteveruse" git branch, but even disregarding the warning, it is not feature complete yet.

[ssam]

there was a thread about fractal trees

http://thread.gmane.org/gmane.comp.file-systems.btrfs/16484

the devs were mostly unconvinced/unimpressed.

http://btrfs.ipv5.de/index.php?title=FAQ#When_will_Btrfs_have_a_fsck_like_tool.3F

The btrfsck tool in the git master branch for btrfs-progs is now capable of repairing some types of filesystem breakage. It is not well-tested in real-life situations yet. If you have a broken filesystem, it is probably better to use btrfsck with advice from one of the btrfs developers, just in case something goes wrong. (But even if it does go badly wrong, you've still got your backups, right?)

plus there is a whole load of runtime error checking, and things like checksumming that will find errors that no fsck ever could.

that said, all code has bugs. there ext family have been widely used for a long time, so chance of hitting an undiscovered bug is slim. its hard to know how widely used btrfs is, but there are bound to be a few nasty surprises left in it. so have a play, but make sure you have good backups.

[devsk]

Why would anybody use a substandard solution when a superior solution (zfsonlinux.org) is available? Its just a kernel module away! No patching and compiling the kernel needed!

In my testing over the years, ZFS has been more stable than BTRFS by orders of magnitude, and is superior in every possible aspect.

[mmmbop]

+1 for zfs on Linux. I've had a couple drive failures and all were handled well by zfs. From the easy to use commandline tools to the complete lack of data loss, I have nothing but good things to say about it.

[garytr24]

It's faster than ext4 if you use lzo compression, at least on spinning disks. I'll happily trade some cpu time for reduced I/O.

[BlueJayofEvil]

I have to repeat what a user on the Sabayon forums stated:

btrfs, well, not quite ready for prime time, IMHO. randomly, I/O consumes all CPU and leaves the machine non responsive for 5seconds or 2-4 minutes. btrfs-endio is stuck at the top of the chart.

really got tired of the system "btrfs-endio" chewing the machine to bits just when I was using it. No real solution seemed available. Looks like the xfs crew was correct in their assessment ;-) it's ext4 with b-trees and a new codebase. ugh!

I've had the same problem on Ubuntu, Fedora, Sabayon, and several other distros while using btrfs (fresh installs each time.) Having your system completely lock up for anywhere between 5 seconds to over a minute is unacceptable, especially on a desktop system.

[crazycheese]

Well, according to this, btrfs matches ext4 in consequent writes, and wins over zfs and ext4 in random write. Which means btfs has its place in terms of performance. : ) Anti-silent bit-flip is very important feature though.