On Sun, May 17, 2015 at 6:08 PM, Stefan G. Weichinger <li...@xunil.at> wrote: > > There were problems with btrfs and the kernel a few months ago (Rich > Freeman was hit by that, maybe he chimes in here), but in general for me > it is still a very positive experience. >
It is nowhere near the stability of ext4. In the last year I've probably had 2-3 periods of time where I was getting frequent panics, or panics anytime I'd mount my filesystems rw. That said, I've never had an occasion where I couldn't mount the filesystem ro, and I've never had an actual loss of committed data. Just downtime while I sorted things out. I do keep a full daily rsnapshot backup on ext4 right now since I consider btrfs experimental. However, if I were too cheap to do that I wouldn't have actually lost anything yet. On the other hand, both btrfs and zfs will get you a level of data security that you simply won't get from ext4+lvm+mdadm - protection from silent corruption. The only time I've ever had a filesystem eat my data on linux was on ext4+lvm+mdadm actually - when I googled for the specific circumstances I think I ran into one guy on a list somewhere who had the same problem, but it is pretty rare (and one piece of advice I would give to anybody using lvm is to backup your metadata - if I had done that and was more careful about running fsck in repair mode I probably could have restored everything without issue). (For the curious, the issue was that I repaired a bunch of fsck-detected problems in one filesystem and lost a lot of data in another one. I suspect that LVM got its mapping messed up somehow, and it might have had to do with operating in degraded mode (perhaps due to a crash and need for rebuild).) A big advantage of btrfs/zfs is that everything is checksummed on disk, and the filesystem is not going to rely on anything that isn't internally consistent. In the event of a rebuild/etc it can always tell which copies are good/bad, unless you do something really crazy like split an array onto two PCs, then rebuild both, and then try to start mix the disks back together - from what I've heard btrfs lacks generation numbers/etc needed to detect this kind of problem. For personal use btrfs is great for playing around with the likely future default linux filesystem. I wouldn't go installing it on production servers in a workplace unless it was a really niche situation, and then only with appropriate steps to mitigate the risks (lots of testing of new kernel releases, backups or an ability to regenerate the system, etc). I wouldn't go so far as to say that there are no circumstances where it is the right tool for the job. You should understand the pros/cons before using it, as with any tool. -- Rich
