Le 15/10/2013 21:12, Paul B. Henson a écrit : >> From: matthew patton [mailto:pattonme@xxxxxxxxx] 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) -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
