Re: good bcache use case?

[Gabriel de Perthuis <g2p.code-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Le 15/10/2013 21:12, Paul B. Henson a écrit :
>> From: matthew patton [mailto:pattonme-/E1597aS9LQAvxtiuMwx3w@public.gmane.org] Sent: Tuesday, 
>> October 15, 2013 8:00 AM
>> 
>> Anything shy of the official linux 3.11.5 kernel release has 
>> several time-bomb bugs.
> 
> Hmm, given 3.10 is an LTS kernel presumably these bug fixes would be 
> back ported? I suppose it would just be a matter of making sure for
> a given 3.10.x that they had been.

3.10.x and 3.11.y stable kernels have been getting bcache backports
whenever necessary.  3.11.4 had a regrettable crasher in writeback mode,
but no time-bomb.  The confusion may come from the fact that the patch
that introduced the crash was fixing a more serious bug.  Stopping here
because the mailing list is starting to feel like Groundhog day.

>> personally would be a bit circumspect in calling it fully 
>> production ready. I don't believe there are any known significant
>> bugs but with the recent flurry of fixes I'd liken it's solidity as
>> more pudding rather than cake.
> 
> Well, that's not exactly a ringing endorsement :). I suppose I could 
> always stick with plan A and migrate to bcache later, it should be 
> easy enough to pvmove everything off of the SSD raid1, pvremove it, 
> and then with a little downtime convert the raid10 to a backing
> store and the SSD raid1 to a cache.
> 
> Thanks for the opinions.

Right now I have in-place conversion for LVs, but not for PVs (details
on the bcache wiki).  The block layout would work for PV conversions,
but since LVM can do raid and a single cache can cache multiple devices,
I've assumed putting bcache on top is preferable.  Maybe for people who
do a lot of snapshotting the other option is better.  (Do as you prefer,
just thinking out loud)