I have been running into this (curtin 18.1-17-gae48e86f-0ubuntu1~16.04.1)
I think this commit basically agrees with my thoughts but I just wanted to share them explicitly in case they are interesting
(1) If you *unregister* the cache device from the backing device, it first has to purge all the dirty data back to the backing device. This may obviously take a while.
(2) When doing that, I managed to deadlock bcache at least once on xenial-hwe 4.15 where it was trying to reclaim memory from XFS, which I assume was trying to write to the bcache.. traceback: https://pastebin.canonical.com/117528/ - you can't get out of that without a reboot
(3) However generally I had good luck simplying "stop"ing the cache devices (it seems perhaps that is what this bug is designed to do, switch to stop, instead of unregister?). Specifically though I was stopping the backing devices, and then later the cache device. It seems like the current commit is the other way around?
I have been running into this (curtin 18.1-17- gae48e86f- 0ubuntu1~ 16.04.1)
I think this commit basically agrees with my thoughts but I just wanted to share them explicitly in case they are interesting
(1) If you *unregister* the cache device from the backing device, it first has to purge all the dirty data back to the backing device. This may obviously take a while.
(2) When doing that, I managed to deadlock bcache at least once on xenial-hwe 4.15 where it was trying to reclaim memory from XFS, which I assume was trying to write to the bcache.. traceback: https:/ /pastebin. canonical. com/117528/ - you can't get out of that without a reboot
(3) However generally I had good luck simplying "stop"ing the cache devices (it seems perhaps that is what this bug is designed to do, switch to stop, instead of unregister?). Specifically though I was stopping the backing devices, and then later the cache device. It seems like the current commit is the other way around?