* What is recommended level of btrfs-progs and kernel please
@ 2018-04-28 14:09 David C. Partridge
2018-04-29 8:03 ` Duncan
0 siblings, 1 reply; 2+ messages in thread
From: David C. Partridge @ 2018-04-28 14:09 UTC (permalink / raw)
To: linux-btrfs
To what level of btrfs-progs do you recommend I should upgrade once my
corrupt FS is fixed? What is the kernel pre-req for that?
Would prefer not to build from source ... currently running Ubuntu 16.04LTS
Thanks
David
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: What is recommended level of btrfs-progs and kernel please
2018-04-28 14:09 What is recommended level of btrfs-progs and kernel please David C. Partridge
@ 2018-04-29 8:03 ` Duncan
0 siblings, 0 replies; 2+ messages in thread
From: Duncan @ 2018-04-29 8:03 UTC (permalink / raw)
To: linux-btrfs
David C. Partridge posted on Sat, 28 Apr 2018 15:09:07 +0100 as excerpted:
> To what level of btrfs-progs do you recommend I should upgrade once my
> corrupt FS is fixed? What is the kernel pre-req for that?
>
> Would prefer not to build from source ... currently running Ubuntu
> 16.04LTS
The way it works is as follows:
In normal operation, the kernel does most of the work, with commands such
as balance and scrub simply making the appropriate calls to the kernel to
do the real work. So the kernel version is what's critical in normal
operation. (IIRC, the receive side of btrfs send/receive is an
exception, userspace is doing the work there, tho the kernel does it on
the send side.)
This list is mainline and forward-looking development focused, so
recommended kernels, the ones people here are most familiar with, tend to
be relatively new. The two support tracks are current and LTS, and we
try to support the latest two kernels of each. On the current kernel
track, 4.16 is the latest, so the 4.16 and 4.15 series are currently
supported. On the LTS track, 4.14 is the newest LTS series and is
recommended, with 4.9 the previous one, still supported, tho as it gets
older and memories of what was going on at the time fade, it gets harder
to support.
That doesn't mean we don't try to help people with older kernels, but
truth is, the best answer may well be "try it with a newer kernel and see
if the problem persists".
Similarly for distro kernels, particularly older ones. We track mainline
and in general[1] have little idea what patches specific distros may have
backported... or not. With newer kernels there's not so much to backport,
and hopefully none of their added patches actually interferes, but
particularly outside the mainline LTS series kernels, and older than the
second newest LTS series kernel for the real LTS distros, the distros
themselves are choosing what to backport and support, and thus are in a
better position to support those kernels than we on this list will be.
But when something goes wrong and you need to use the debugging tools or
btrfs check or restore, it's the btrfs userspace (btrfs-progs) that is
doing the work, so it becomes the most critical when you have a problem
you are trying to find/repair/restore-from.
So in normal operation, userspace isn't critical, and the biggest problem
is simply keeping it current enough that the output remains comparable to
current output. With btrfs userspace release numbering following that of
the kernel, for operational use, a good rule of thumb is to keep
userspace updated to at least the version of the oldest supported LTS
kernel series, as mentioned 4.9 at present, thus keeping it at least
within approximately two years of current.
But once something goes wrong, the newest available userspace, or close
to it, has the latest fixes, and generally provides the best chance at a
fix with the least hassle or chance of further breakage instead. So
there, basically something within the current track, above, thus
currently at least a 4.15 if not a 4.16 userspace (btrfs-progs) is your
best bet.
And often the easiest way to get that if your distro doesn't make it
directly available, is to make it a point to keep around the latest
LiveRescue (often install/rescue combined) image of a distro such as
Fedora or Arch that stays relatively current. That's often the newest or
close enough, and if it's not, it at least gives you a way to get back
online to fetch something newer after booting the rescue image, if you
have to.
---
[1] In general: I think one regular btrfs dev works with SuSE, and one
non-dev but well-practiced support list regular is most familiar with
Fedora, tho of course Fedora doesn't to be /too/ outdated.
--
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-04-29 8:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-28 14:09 What is recommended level of btrfs-progs and kernel please David C. Partridge
2018-04-29 8:03 ` Duncan
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.