Re: 3.18.1 + latest bcache-dev

Slava Pestov
2015-01-05T07:47:31Z

On Sun, Jan 4, 2015 at 6:11 AM, Rolf Fokkens <rolf@rolffokkens.nl> 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:
> https://github.com/karelzak/util-linux/blob/master/libblkid/src/superblocks/bcache.c
>
> Furthermore I think I should postpone integration of bcache in the Fedora
> installer until further notice:
> https://bugzilla.redhat.com/show_bug.cgi?id=1003208
>
> 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.
>
>