All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.