Re: "/tmp/mnt.", and not honouring compression

[Chris Murray <chrismurray84@gmail.com>]

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 userspace from getting /too/ far behind and
> because
> userspace release version numbers are synced with kernel version, a
> good
> rule of thumb is to run a userspace version similar to that of your
> kernel, or newer.  Assuming you're already following the current or
> LTS
> track kernel recommendations, that will keep you reasonably current,
> and
> you can always upgrade to the newest available if you're trying to fix
> otherwise unfixable problems.
> 
> Unfortunately your userspace falls well outside that recommendation as
> well, with 3.17 userspace being before the earliest supported 3.18 LTS
> kernel, let alone comparable to your current 4.2 kernel or the 4.4 LTS
> upgrade or 4.1 LTS downgrade that would be recommended on the LTS
> track,
> or 4.4 or 4.5 on the current track.
> 
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Duncan, many thanks for that comprehensive response.

I was hoping for an "ah-ha, I've seen that!" from someone, but can now
see the position I'm in and the options available. I see there's
probably little to be gained in trying to support my ageing kernel and
btrfs-progs, so I'm happy to leave it at that and not waste anyone's
time.

My workaround for now is to reweight CEPH OSDs to cater for the
'missing' compression on these "/tmp/mnt." mounts - some disks will be
compressed, and some won't, but overall there are at least *some*
savings.

Thanks again,
Chris