On Thu, 2016-03-31 at 23:43 +0100, Duncan wrote:
> Chris Murray posted on Thu, 31 Mar 2016 21:49:29 +0100 as excerpted:
>
> > I'm using Proxmox, based on Debian. Kernel version 4.2.8-1-pve.
> Btrfs
> > v3.17.
>
> The problem itself is beyond my level, but aiming for the obvious low-
> hanging fruit...
>
> On this list, which is forward looking as btrfs remains stabilizing,
> not
> yet fully stable and mature, kernel support comes in four tracks,
> mainstream and btrfs development trees, mainstream current, mainstream
> lts, and everything else.
>
> Mainstream and btrfs development trees should be obvious. It covers
> mainstream current git and rc kernels as well as btrfs-integration and
> linux-next. Generally only recommended for bleeding edge testers
> willing
> to lose what they're testing.
>
> Mainstream current follows mainstream latest releases, with generally
> the
> latest two kernel series being best supported. With 4.5 out, that's
> 4.5
> and 4.4.
>
> Mainstream LTS follows mainstream LTS series, and until recently,
> again
> the latest two were best supported. That's the 4.4 and 4.1 LTS
> series.
> However, as btrfs has matured, the previous LTS series, 3.18, hasn't
> turned out so bad and remains reasonably well supported as well, tho
> depending on the issue, you may still be asked to upgrade and see if
> it's
> still there in 4.1 or 4.4.
>
> Then there's "everything else", which is where a 4.2 kernel such as
> you're running comes in. These kernels are either long ago history
> (pre-3.18 LTS, for instance) in btrfs terms, or out of their
> mainstream
> kernel support windows, which is where 4.2 is. While we recognize
> that
> various distros claiming btrfs support may still be using these
> kernels,
> because we're mainline focused we don't track what patches they may or
> may not have backported, and thus aren't in a particularly good
> position
> to support them. If you're relying on your distro's support in such a
> case, that's where you need to look, as they know what they've
> backported
> and what they haven't and are thus in a far better position to provide
> support.
>
> As for the list, we still do the best we can with these "everything
> else"
> kernels, but unless it's a known problem recognized on-sight, that's
> most
> often simply to recommend upgrading to something that's better
> supported
> and trying to duplicate the problem there.
>
> Meanwhile, for long-term enterprise level stability, btrfs isn't
> likely
> to be a good choice in any case, as it really is still stabilizing and
> the expectation is that people running it will be upgrading to get the
> newer patches. If that's not feasible, as it may not be for the
> enterprise-stability-level use-case, then it's very likely that btrfs
> isn't a good match for the use-case anyway, as it's simply not to that
> level of stability yet. A more mature filesystem such as ext4, ext3,
> the
> old reiserfs which I still use on some spinning rust here (all my
> btrfs
> are on ssd), xfs, etc, is very likely to be a more appropriate choice
> for
> that use-case.
>
> For kernel 4.2, that leaves you with a few choices:
>
> 1) Ask your distro for btrfs support if they offer it on the out-of-
> mainline-support kernels which they've obviously chosen to use instead
> of
> the LTS series that /are/ still mainline supported.
>
> 2) Upgrade to the supported 4.4 LTS kernel series.
>
> 3) Downgrade to the older supported 4.1 LTS kernel series.
>
> 4) Decide btrfs is inappropriate for your use-case and switch to a
> fully
> stable and mature filesystem.
>
> 5) Continue with 4.2 and muddle thru, using our "best effort" help
> where
> you can and doing without or getting it elsewhere if the opportunity
> presents itself or you have money to buy it from a qualified provider.
>
>
> Personally I'd choose option 2, upgrading to 4.4, but that's just me.
> The other choices may work better for you.
>
>
> As for btrfs-progs userspace, when the filesystem is working it's not
> as
> critical, since other than filesystem creation with mkfs.btrfs, most
> operational commands simply invoke kernel code to do the real work.
> However, once problems appear, a newer version can be critical as
> patches
> to deal with newly discovered problems continue to be added to tools
> such
> as btrfs check (for detecting and repairing problems) and btrfs
> restore
> (for recovery of files off an unmountable filesystem). And newer
> userspace is designed to work with older kernels, so newer isn't a
> problem in that regard.
>
> As a result, to keep users
