On Sun, 10 Aug 2014 07:39:00 -0700, Marc MERLIN wrote: > My apologies if I missed some Emails, but I'm a bit confused. > The deadlocks happen reliably with 3.15+, but those patches are marked as > being for 3.14 in your URL, but then you say you didn't backport them to > 3.14.
sigh :) My patch queue is meant for 3.14 only. The notorious hangs in 3.15+ are a different issue, as we have seen likely caused by the workqueue changes; I was only interested in keeping & improving 3.14.x, precisely because 3.15 is still borked and short-lived, and 3.16 has exciting new, completely btrfs-unrelated problems for which I really don't have much patience at the moment. > That said, if you'd like to me try a set of patches that applies to > 3.15.latest or 3.16 to see if they stop my frequent btrfs deadlocks, I'd be > happy to. I meant you could try my patch queue if you intend to use 3.14.x for a longer period of time since it's a longterm kernel. If and when The Great Hang has been fixed I migh look at 3.16+ again, but thanks to the quite unhelpful general btrfs backport policy I'm not holding my breath. "Simply use the latest kernel" is laughably impractical for many reasons, and for the majority of people it's just easier to not use btrfs at all - which helps nobody. The - admittedly poorly worded - "backporting" referred to getting a set of identified patches (aka my queue) into 3.14-longterm via Greg KH; there is nothing to do except apply them. > If the patches are meant for 3.14, that's not very helpful since 3.14 is > reasonably stable for me in comparison. ..which is precisely what I said and why I'm using it. :) That does not mean problems identified post-3.14 cannot or should not be patched if they are being addressed in other trees and apply easily. -h -- 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
