On Fri, Jun 27, 2014 at 11:52 AM, Chris Murphy <li...@colorremedies.com> wrote: > On Jun 27, 2014, at 9:14 AM, Rich Freeman <r-bt...@thefreemanclan.net> wrote: > >> >> I got another block this morning and failed to capture a log before my >> terminals gave out. I switched back to 3.15.0 for the moment, and >> we'll see if that fares any better. > > Yeah I'd start going backwards. The idea of going forwards is to > hopefully get you unstuck or extract data where otherwise you can't, > it's not really a recommendation for production usage. It's also often > useful if you can reproduce the block with a current rc kernel and > issue sysrq+w and post that. Then do your regression with an older > kernel.
So, obviously I'm getting my money's worth from the btrfs team, but neither is always a great option as neither involves me running a stable kernel. 3.15.0 contains CVE-2014-4014, although I'm running a version patched for that vulnerability. If I go back any further I'd probably have to backport it myself, and I only know about it because my distro patched that CVE on 3.15.0 before moving to 3.15.1. Running 3.16 doesn't bother me much from a btrfs standpoint, but it means I'm getting unstable updates on all the other modules as well. It is just more to deal with. I might give 3.15.2 a shot and see what happens, and I can always fall back to 3.15.0 again. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
