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
next prev 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).