I enabled discard on the bcache backing a large filesystem with writeback caching a few weeks ago. Yesterday I restarted the system cleanly and it failed to come back. I see the following in the log: Mar 04 19:04:18 archiso kernel: bcache: prio_read() bad csum reading priorities Mar 04 19:04:18 archiso kernel: bcache: bch_cache_set_error() error on 6432e656-f28e-49f8-943d-6307d42d37e9: IO error reading priorities, disabling caching The backing devices are all marked dirty when I check with bcache-super-show. I see threads going back years mentioning this problem: https://www.spinics.net/lists/linux-bcache/msg02712.html https://www.spinics.net/lists/linux-bcache/msg02954.html https://www.spinics.net/lists/linux-bcache/msg04668.html https://www.spinics.net/lists/linux-bcache/msg05279.html There is also a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=197377 The cache device backs a large BTRFS volume made up of many spinning disks and, while I have a backup, it’s offsite and will take a huge amount of time to restore. Since I’m running BTRFS with some redundancy, I would love to do whatever I can to get things back to as good a state as possible and try a scrub. I tried building bcache myself and skipping loading priorities, since comments suggest they’re nonessential, and the next thing I hit is: Mar 04 15:32:56 archiso kernel: bcache: bch_cache_set_error() error on 6432e656-f28e-49f8-943d-6307d42d37e9: unsupported bset version at bucket 108857, block 0, 79054670 keys, disabling caching Note that I’m not familiar with bcache internals and this is actually my first time building a kernel module to debug something. What can I do here? And should discard even be available as an option if it fails this badly?
