Am Mon, 4 Apr 2016 04:34:54 +0000 (UTC) schrieb Duncan <1i5t5.duncan@xxxxxxx>: > Meanwhile, putting bcache into write-around mode, so it makes no > further changes to the ssd and only uses it for reads, is probably > wise, and should help limit further damage. Tho if in that mode > bcache still does writeback of existing dirty and cached data to the > backing store, some further damage could occur from that. But I > don't know enough about bcache to know what its behavior and level of > available configuration in that regard actually are. As long as it's > not trying to write anything from the ssd to the backing store, I > think further damage should be very limited. bcache has 0 for dirty data most of the time for me - even in write back mode. It does write back during idle time and at reduced rate, usually that finishes within a few minutes. Switching the cache to write-around initiates instant write-back of all dirty data, so within seconds it goes down to zero and the cache becomes detachable. I'll go test the soon-to-die SSD as soon as it replaced. I think it's still far from failing with bitrot. It was overprovisioned by 30% most of the time, with the spare space trimmed. It certainly should have a lot of sectors for wear levelling. In addition, smartctl shows no sector errors at all - except for one: raw_read_error_rate. I'm not sure what all those sensors tell me, but that one I'm also seeing on hard disks which show absolutely no data damage. In fact, I see those counters for my hard disks. But dd to /dev/null of the complete raw hard disk shows no sector errors. It seems good. But well, counting 1+1 together: I currently see data damage. But I guess that's unrelated. Is there some documentation somewhere what each of those sensors technically mean and how to read the raw values and thresh values? I'm also seeing multi_zone_error_rate on my spinning rust. According to smartctl health check and smartctl extended selftest, there's no problems at all - and the smart error log is empty. There has never been an ATA error in dmesg... No relocated sectors... From my naive view the drives still look good. -- Regards, Kai Replies to list-only preferred. -- 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
