public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Priebe <s.priebe-2Lf/h1ldwEHR5kwTpVNS9A@public.gmane.org>
To: Kent Overstreet <kmo-PEzghdH756F8UrSeD/g0lQ@public.gmane.org>,
	"Paul B. Henson" <henson-HInyCGIudOg@public.gmane.org>
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: 3.10LTS ok for production?
Date: Sat, 09 Nov 2013 08:11:35 +0100	[thread overview]
Message-ID: <527DE027.2050606@profihost.ag> (raw)
In-Reply-To: <20131109064721.GC30271@kmo-pixel>

at least i'm suffering from two problems on 3.10:

1.) dirty value is often wrong / can go negative
2.) writeback cache is only cleared / written back when having 
writeback_percent => 0

The first one is already fixed by kent - just waiting for a backport.

Greets,
Stefan

Am 09.11.2013 07:47, schrieb Kent Overstreet:
> On Fri, Nov 08, 2013 at 07:01:28PM -0800, Paul B. Henson wrote:
>> I'd kinda like to use the 3.10 LTS kernel for a virtualization server
>> I'm building, but it seems like every time somebody reports a problem
>> the recommendation is to make sure you're using the latest bleeding edge
>> kernel. Is it intended for bcache to be considered production ready in
>> the 3.10 LTS branch, or do you pretty much have to run the latest stable
>> of the week for now if you want to be sure to get all the bcache bugfixes
>> necessary for a stable system? Specifically, I'd like to use a raid1 of 2
>> 256G SSDs to be a write-back cache for a raid10 of 4 2TB HDs. Occasional
>> reboots aren't an issue for kernel updates, but I'd prefer to avoid the
>> potential instability and config churn of tracking the mainline kernel.
>
> Yes - 3.10 LTS (or 3.11) has been what you want to be running for awhile
> now; I've been making sure all the bugfixes get backported quickly. The
> only bugfix I know of that I wasn't backported was a fix for a suspend
> issue, because it was part of a fairly involved allocator rework.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2013-11-09  7:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-09  3:01 3.10LTS ok for production? Paul B. Henson
     [not found] ` <20131109030128.GJ5474-eJ6RpuielZ6oHZ9hTG1MgCsmlnnoMqry@public.gmane.org>
2013-11-09  5:29   ` Matthew Patton
     [not found]     ` <op.w59n7e06f3gqgg-r49W/1Cwd2cba4AQcYcrVKxOck334EZe@public.gmane.org>
2013-11-13  0:17       ` Paul B. Henson
2013-11-09  6:47   ` Kent Overstreet
2013-11-09  7:11     ` Stefan Priebe [this message]
     [not found]       ` <527DE027.2050606-2Lf/h1ldwEHR5kwTpVNS9A@public.gmane.org>
2013-11-13  0:21         ` Paul B. Henson
2013-11-13  0:21     ` Paul B. Henson

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=527DE027.2050606@profihost.ag \
    --to=s.priebe-2lf/h1ldwehr5kwtpvns9a@public.gmane.org \
    --cc=henson-HInyCGIudOg@public.gmane.org \
    --cc=kmo-PEzghdH756F8UrSeD/g0lQ@public.gmane.org \
    --cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.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