[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

On Mon, Jul 11, 2016 at 09:12:43AM +0100, Dimitri John Ledkov wrote:
> On 11 July 2016 at 04:07,  <german398@ya.ru> wrote:
> >>Say what you want.
> >
> > Now I want to know if Debian Stable can in some extreme cases, like in
> > this case with btrfs, replace not_very_good kernel module that is
> > shipped with its current kernel with a kernel module from other (older
> > or newer) version of Linux kernel and if yes, is it the case with btrfs?
> Use linux kernel from backports, it's at 4.6.1 at the moment.

Actually, I'd recommend not.

2.6.32 had btrfs with plenty of bugs.  Do not use!
3.2 was quite stable, at least for non-RAID (or md or hw RAID).
3.16 works fine.
As btrfs still moves quite fast, regressions happen, and usually get fixed
before Linus gets to make a non-rc tag.  4.6 is quite an exception as
there's at least one rare bug still unfixed.  Being elusive to reproduce
means it's unlikely to happen in real use, and even when intentionally
tickling it, it hasn't corrupted data for anyone.  But still, a bug is a
bug, thus I'd recommend keeping to 4.5 for now.  Or, if you're running
stable, 3.16.

Ie, stable is more stable than cutting edge (duh!).

And as for btrfs stability in general: quote a few companies offer
commercial support.  And from my own experiences: I have been using btrfs
extensively for years, for vservers, backups, a ceph cluster, even an arm
build box, without a single issue on non-hot kernels.  To the contrary:
I had a case where btrfs let me recover from a hardware failure where ext4
would not: an unreadable file had its previous generation still readable.
Filesystems that overwrite in-place do corrupt data when a write has a
hardware error...

I somehow never happened to use btrfs RAID 0/1/10 (people I work with
believe in hw RAID), so no personal experiences there.  It is said to be
reliable these days.

On the other hand, there _is_ a big fat problem: I see no warnings in "man
mkfs.btrfs" and friends on either jessie or unstable about RAID 5/6 being
highly experimental and indeed eating data.  It should be obnoxious to the
level of dpkg when you try to remove essential.  This is a communication
problem, when the same piece of software has both stable and experimental
features, yet fails to mark them properly.

An imaginary friend squared is a real enemy.

Reply to: