> I did a scrub with bcache running and 19 errors were found and corrected > using duplicate metadata. That seems encouraging. What kind of scrub? Did it affect bcache caching or backing device? > Unfortunately, I can't > seem to shut down bcache in order to test as you suggest. I can stop > bcache0 but I am unable to stop the cache device. I do the usual: > > echo 1 > /sys/fs/bcache/dc2877bc-d1b3-43fa-9f15-cad018e73bf6/stop I was seeing a similar issue. I'm not sure "stop" always works as expected. You should try "detach" instead. When it finished writeback eventually, it would detach cache from backing, and upon next mount they won't be attached to each other any longer and you should be able to unmount. If you cannot get rid of dirty data, you could also unregister bcache, then wipe the cache device, and then re-register and force-run the bcache backing device. Tho, discarding write-back data will eventually damage your FS. You should try switching to write-around first and see if you can convince bcache to write back data that way (maybe through a clean reboot after switching to write-around). > ... and nothing happens. I assume that's because it can't do a clean > shutdown. Is there any other way to unload bcache? I needed to bump the minimum writeback rate up to get that done in time. But I think you're facing a different problem than I had. My bcache btree was technically okay. > My alternative is to dig up a bootable usb drive that doesn't auto-start > bcache. So far, all of the boot images I've tried init bcache automatically. You could try disabling the bcache module, or if using dracut, "rd.break=pre-mount" or similar break-points may work. HTH Kai