All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Russell Coker <russell@coker.com.au>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: 3.16.0 Debian kernel hang
Date: Fri, 4 Dec 2015 08:53:07 -0500	[thread overview]
Message-ID: <56619AC3.5000309@gmail.com> (raw)
In-Reply-To: <201512050042.32497.russell@coker.com.au>

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

On 2015-12-04 08:42, Russell Coker wrote:
> On Sat, 5 Dec 2015 12:08:58 AM Austin S Hemmelgarn wrote:
>>> I know that there are no plans to backport things to 3.16 and I don't
>>> think the Debian people are going to be very interested in this.  So
>>> this message is a FYI for users, maybe consider not using the
>>> Debian/Jessie kernel for BTRFS systems.
>>
>> I'd suggest extending that suggestion to:
>> If you're not using an Enterprise distro (RHEL, SLES, CentOS, OEL), then
>> you should probably be building your own kernel, ideally using upstream
>> sources.
>
> There are lots of ways of dealing with this.
>
> Debian development doesn't stop.  Anyone who is running a Jessie system can
> easily run a kernel from Testing or Unstable (which really isn't particularly
> unstable).  It's generally expected that Debian user-space will work with a
> kernel from +- one release of Debian.  Also every time I've tried it Debian
> has worked well with a CentOS kernel of a similar version.
Well yes, that does usually work, but that doesn't mean that it keeps up 
with mainline very well.  Back when I used Debian on a regular basis, I 
ran the 'unstable' kernels, and they still lagged behind mainline by at 
least a minor version, and often more than that.  And there have been 
cases where things got horribly broken in mainline due to lack of proper 
vetting of code (Most recent example being the insanity with the 
clustered MD code, which broke non-clustered soft raid for at least two 
major releases), which prevents them from safely keeping up-to-date with 
mainline.
>
> The only reason I'm not running Unstable kernels on my Debian systems is
> because I run some Xen servers and upgrading Xen is problemmatic.  Linode is
> moving from Xen to KVM so I guess I should consider doing the same.  If I
> migrate my Xen servers to KVM I can use newer kernels with less risk.
That's interesting, that must be something with how they do kernel 
development in Debian, because I've never had any issues upgrading 
either Xen or Linux on any of the systems I've run Xen on, and I 
directly track mainline (with a small number of patches) for Linux, and 
stay relatively close to mainline with Xen (Gentoo doesn't have all that 
many patches on top of the regular release for Xen, aside from XSA patches).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-12-04 13:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 10:00 3.16.0 Debian kernel hang Russell Coker
2015-12-04 13:08 ` Austin S Hemmelgarn
2015-12-04 13:42   ` Russell Coker
2015-12-04 13:53     ` Austin S Hemmelgarn [this message]
2015-12-04 14:26       ` Russell Coker
2015-12-04 16:13         ` Austin S Hemmelgarn
2015-12-05 12:44   ` Duncan

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=56619AC3.5000309@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=russell@coker.com.au \
    /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.