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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
