On 10/30/2019 3:18 PM, Kai Krakow wrote:
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?
btrfs scrub. Not sure what, if anything, was actually effected.
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).
Duh, yes, unregistering the backing device did what I needed. I'm now
running a new scrub without the cache device. Interestingly, the initial
scrub speed with bcache ran at 900MB/s and without bcache it's 1400MB/s.
... 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
Thanks for the un-register tip!
--Larkin
