Marc MERLIN wrote (ao): > That said, it's working fine again for now after I went back to kernel 3.5.3 > (down from 3.6.3). It hasn't been long enough to say for sure, but there is > a remote possibility that changes in 3.6 actually caused my drive to freeze > after several hours of use. > When that happened (3 times), 2 of those times, btrfs did not manage to > write all its data before access was cutoff, and I got the bug I reported > here, which in turn crashes any kernel you try to mount the FS with. > Cleaning the log manually fixed it both times so far. > > For now, I'll stick with 3.5.3 for a while to make sure my drive is actually > ok (it seems to be afterall), and once I'm happy that it's the case, I'll go > back to 3.6.3 with serial console remote logging and try to capture the full > sata failure I got with 3.6.3. Thanks for the info. You could put some load on the ssd to see if you can trigger an issue under 3.6.3(+) with btrfs filesystem scrub or badblocks (in the default non-destructive mode). Can you collect SMART data (with smartctl) from the ssd? Sander -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
