linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: "Christian Völker" <cvoelker@knebb.de>, linux-btrfs@vger.kernel.org
Subject: Re: Resizing BTRFS - raw partition
Date: Wed, 2 Nov 2016 11:14:46 +0100	[thread overview]
Message-ID: <20161102101446.GB29764@angband.pl> (raw)
In-Reply-To: <20161102092926.GM16645@carfax.org.uk>

On Wed, Nov 02, 2016 at 09:29:26AM +0000, Hugo Mills wrote:
> On Wed, Nov 02, 2016 at 10:18:03AM +0100, Christian Völker wrote:
> > thanks for the quick reply. Regarding version- I prefer to use stable
> > Linux versions....and I am not going to upgrade just btrfs outside of
> > the verndors builds. So I am stuck happily with this version. And I run
> > Linux since more than 10years, so I am really fine with it, I guess :D
> 
>    Well, btrfs-progs 0.19 was last released several years ago. If your
> kernel is of the same kind of age, then you're going to be seeing a
> whole load of really nasty data-corrupting or filesystem-breaking bugs
> which have since been fixed. Basically, if something goes wrong with
> your FS when you're running a kernel that old, the main rsponse you'll
> get is, "well, that was silly of you, wasn't it?", and you'll have to
> make a new filesystem and restore from your backups and hope it
> doesn't happen again.

-progs 0.19 imply kernel 2.6.32 which comes from btrfs' infancy, when it
was hardly merged into mainline.  It's buggier than experimental features
like RAID5/6 nowadays.

>    I would currently recommend running a 4.4 kernel or later. If you
> want a "stable" kernel version from a distribution, and want some kind
> of support for it when it goes wrong, you're probably going to have to
> pay someone (Red Hat or SuSE, most likely) to support your
> configuraion.

Kernels around 3.16 or so are pretty reliable -- ones I'm using on
production are 3.13 and 3.14, without a single issue.

As 2.6.32 is for you "stable" rather than "ancient and unsupported", I guess
you're on RHEL or a derivative.  For them, 3.10 is the next stable, which
is on the verge of what could be reasonable (but I still second Hugo's
advice of using at least the current LTS kernel, ie 4.4).

TL;DR:
DO NOT USE BTRFS ON ANCIENT KERNELS!!1!elebenty-one!


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

  reply	other threads:[~2016-11-02 10:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02  8:58 Resizing BTRFS - raw partition Christian Völker
2016-11-02  9:12 ` Hugo Mills
2016-11-02  9:18   ` Christian Völker
2016-11-02  9:29     ` Hugo Mills
2016-11-02 10:14       ` Adam Borowski [this message]
2016-11-02 10:16         ` Christian Völker
2016-11-02 11:40     ` Austin S. Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161102101446.GB29764@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=cvoelker@knebb.de \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).