archive mirror
 help / color / mirror / Atom feed
From: Slava Pestov <>
To: Rolf Fokkens <>
Cc: Kent Overstreet <>,
	"Stephen R. van den Berg" <>,
Subject: Re: 3.18.1 + latest bcache-dev
Date: Sun, 4 Jan 2015 23:47:30 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Jan 4, 2015 at 6:11 AM, Rolf Fokkens <> wrote:
> Please let us know when this will be pushed to the kernel, do you have any
> thoughts on the planning of this?
> As a bcache-tools packager for Fedora I think I should add some package
> dependencies which prevent users from accidentally upgrading to that
> (breaking) version in the future.

The plan is to incrementally backport bug fixes and optimizations from
bcache-dev to upstream for the foreseeable future.

The development branch is going through major changes to support
dynamically adding/removing cache devices and storing data in the
btree instead of using it as a cache, enabling usage without any
backing devices. We're actively working on this code and doing a lot
of stress testing of both the new stuff and backing device support.
However, it's its too early to tell what the new features will look
like by the time they're ready to go upstream, or what a transition
plan will look like for existing installs.

I wish we had more time for upstreaming stuff, but I can assure you
its not Kent's intent to just dump bcache-dev as one huge pull request

> It may also affect other tools like util-linux:
> Furthermore I think I should postpone integration of bcache in the Fedora
> installer until further notice:
> Any information in advance is appreciated.
> Rolf
> On 01/04/2015 01:46 AM, Kent Overstreet wrote:
>> Yes, correct. The on disk format changes in bcache-dev are just too deep
>> to feasibly write backwards compat code, unfortunately. And the on disk
>> format is still in flux - for just a bit longer hopefully though, right now
>> I'm working on a pretty major revamp that's getting close to done (self
>> describing and packed metadata). This revamp is making the on disk format
>> _much_ more flexible though, and cleaning up a lot of stuff at the same
>> time.

  reply	other threads:[~2015-01-05  7:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-28  2:35 Stephen R. van den Berg
2014-12-29  4:05 ` Slava Pestov
2015-01-03 16:40   ` Rolf Fokkens
2015-01-04  0:46     ` Kent Overstreet
2015-01-04 14:11       ` Rolf Fokkens
2015-01-05  7:47         ` Slava Pestov [this message]
2015-01-06 22:18           ` Rolf Fokkens
2015-01-06 22:47             ` Slava Pestov
2015-01-07  1:48             ` Kent Overstreet
2015-01-07 17:41               ` Jianjian Huo
2015-01-08  2:29                 ` Kent Overstreet
2015-01-07 20:17             ` Eric Wheeler
2015-01-08  2:30               ` Kent Overstreet
2015-01-08 19:47                 ` Rolf Fokkens
2015-01-05  8:49       ` Stephen R. van den Berg
2015-01-05 11:06         ` Kent Overstreet
2015-01-06  9:16           ` Stephen R. van den Berg
2015-01-06 11:10             ` Kent Overstreet

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \
    --subject='Re: 3.18.1 + latest bcache-dev' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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