On May 9, 2014, at 4:35 AM, Marc MERLIN <m...@merlins.org> wrote: > > Howdy, > > I won't have the time to rebuild my laptop tonight, so I'll wait one more > day to see if anyone would like data from that fs to see why it crashed and > why btrfs recovery doesn't even seem able to open it.
There's some underlying reason why it went read only, but we don't have those messages. The message we do have says the kernel is already tainted, so something (possibly entirely unrelated) happened earlier. > Also I'm not sure if I should risk 3.15rc to rebuild the filesystem and I'd > love not to have to say during my talk that even almost latest btrfs > corrupts itself without reason and working recovery methods :-/ Just because the reason isn't yet known or understood yet doesn't mean it's happened without reason. And we also don't know whether it corrupted itself, or had help earlier on. Neither is good, but depending on the cause of the corruption, recovery may not even be realistic. I'd probably consider 3.13.11 if I simply had work that needs to get done rather than testing. If the problem happens there too then you've stumbled on something that isn't likely a regression. If you've done any suspend/hibernate at all, I'd stop doing that until you're in a position to do a lot more rigorous testing. I say that because suspend and hibernate have become so completely unreliable for so many people I know doing testing, including myself, that it's worth avoiding. I've had lots of corruptions, not just Btrfs, related to suspend testing in particular (hibernate doesn't work either but it hasn't corrupted the file system). And there's a bunch of new work happening on suspend in 3.15 so things are probably about to change yet again. Chris Murphy-- 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
