On Fri, Apr 10, 2015 at 8:14 PM, Kai Krakow <hurikhan77@xxxxxxxxx> wrote: >> There are reports about endurance tests that say you can write petabytes >> of data to SSD before they die. Samsung's drives belong to the best >> performers here with one downside: If they die, in those tests they took >> all your data with them and without warning. Most other drives went into >> read-only mode first so you could at least get your data off those drives, >> but after a reboot those drives were dead, too. >> >> http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead This has what to do with bcache eating my data, again? >> From those reports, I conclude: If your drive suddenly slows down, it's a >> good idea to order a replacement and check the SMART stats (if you didn't >> do that before). This as well. The drive didn't die, all sectors are still readable. No errors at all on SMART. >> I'm also not sure to instead call it a general bug or problem of bcache. >> The TRIM implementation seems to be correct, at least it doesn't show >> problems for me. I have TRIM enabled for btrfs, bcache, and the kernel >> claims it to be supported. So I'd rather call it an incompatibility or >> firmware flaw which needs to be worked around. Please explain why no other filesystem, windows OR linux, has errors with TRIM on this drive. The other part I don't understand is that nothing should have been discarded yet - I took the time to flush the cache to disk (echo none > cache_mode), waited for writeback to complete, detach the cdev, waited for the detach to complete, recreate it with the correct blocksize and discard enabled, then re-attach. I ran for maybe 15 minutes like this before rebooting, for perhaps a dozen GB written out of the 200gb cache partition. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
