Re: bcache fails after reboot if discard is enabled

[Dan Merillat <dan.merillat@gmail.com>]

On Fri, Apr 10, 2015 at 8:14 PM, Kai Krakow <hurikhan77@gmail.com> 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.