linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: attempt to mount after crash during rebalance hard crashes server
Date: Tue, 29 Mar 2016 22:55:26 +0000 (UTC)	[thread overview]
Message-ID: <pan$440f4$30656b38$7703d942$803f5cf7@cox.net> (raw)
In-Reply-To: CAHaDNyXRW4FQC+5P2_8apdFan2wtsHnPyzuK5ZPq8dLXW-S9_g@mail.gmail.com

Warren, Daniel posted on Tue, 29 Mar 2016 16:21:28 -0400 as excerpted:

> I'm running 4.4.0 from deb sid

Correction.

According to the kernel panic you posted at...

http://pastebin.com/aBF6XmzA

... you're running kernel 3.16.something.

You might be running btrfs-progs userspace 4.4.0, but on mounted 
filesystems it's the kernel code that counts, not the userspace code.

Btrfs is still stabilizing, and kernel 3.16 is ancient history.  On this 
list we're forward focused and track mainline.  If your distro supports 
btrfs on that old a kernel, that's their business, but we don't track 
what patches they may or may not have backported and thus can't really 
support it here very well, so in that case, you really should be looking 
to your distro for that support, as they know what they've backported and 
what they haven't, and are thus in a far better position to provide that 
support.

On this list, meanwhile, we recommend one of two kernel tracks, both 
mainline, current or LTS.  On current we recommend and provide the best 
support for the latest two kernel series.  With 4.5 out that's 4.5 and 
4.4.

On the LTS track, the former position was similar, the latest two LTS 
kernel series, with 4.4 being the latest and 4.1 the previous one.  
However, as btrfs has matured, now the second LTS series back, 3.18, 
wasn't bad, and while we still really recommend the last couple LTS 
series, we do recognize that some people will still be on 3.18 and we 
still do our best to support them as well.

But before 3.18, and on non-mainline-LTS kernels more than two back, so 
currently 4.4, while we'll still do the best we can, unless it's a known 
issue recognizable on sight, very often that best is simply to ask that 
people upgrade to something reasonably current and report back with their 
results then, if the problem remains.

As for btrfs-progs userspace, during normal operations, most of the time 
the userspace code simply calls the appropriate kernel functionality to 
do the real work, so userspace version isn't as important.  Mkfs.btrfs is 
an exception, and of course once the filesystem is having issues and 
you're using btrfs check or btrfs restore, along with other tools, to try 
to diagnose and fix the problem or at least to recover files off the 
unmountable filesystem, /then/ it's userspace code doing the work, and 
the userspace version becomes far more important.  And userspace is 
written to handle older kernels.

For userspace, a good rule of thumb, therefore, is to run a version at 
least comparable to the kernel you're running.  The release series 
numbers are synced, and as long as you're following the kernel 
recommendations, running at least as new a userspace as the kernel will 
ensure your userspace doesn't get too old either.


Bottom line for you, a 3.16 kernel is too old to practically support on 
this list.  Either check with your distro for support, or upgrade to at 
least the latest 3.18 LTS kernel, and preferably at least the latest 4.1 
LTS.

Meanwhile, btrfs really is still stabilizing, and you may want to 
reconsider whether using a still stabilizing filesystem such as btrfs is 
compatible with your apparent desire to run really old and stale^H^Hble 
distros such as you seem to have chosen.  There are legitimate reasons to 
be conservative and choose really stable over the latest as yet unproven 
code, but such reasons tend to be incompatible with choosing a still 
stabilizing, definitely not yet fully stable and mature, filesystem such 
as btrfs remains at this point.  There's a very good chance that your 
interests will be best served by either choosing a distro and distro 
release that's rather more current, if you really want to follow not yet 
fully stable products such as btrfs, or that if you prefer stable and 
mature, you really should be on a more stable and mature filesystem, 
perhaps ext3 or ext4, or xfs, or the reiserfs that I used for years and 
that I still use on my spinning rust (I run btrfs on my ssds), as since 
it switched to data=ordered by default (as opposed to the data=writeback 
default that got reiserfs its bad stability reputation) it has in my own 
experience been incredibly stable, even on systems with hardware issues 
that made most filesystems (including a then much less stable and mature 
btrfs) unworkable.

-- 
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


  parent reply	other threads:[~2016-03-29 22:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 20:21 attempt to mount after crash during rebalance hard crashes server Warren, Daniel
2016-03-29 20:46 ` Chris Murphy
2016-03-29 21:25   ` Patrik Lundquist
2016-03-29 22:55 ` Duncan [this message]
2016-03-30 14:11   ` Warren, Daniel

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='pan$440f4$30656b38$7703d942$803f5cf7@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).