[Bug 1147412] bcache-register fails during boot, leaving backing store busy
![](https://seccdn.libravatar.org/avatar/3035b38ff33cf86f480bb169b8500b80.jpg?s=120&d=mm&r=g)
http://bugzilla.suse.com/show_bug.cgi?id=1147412
http://bugzilla.suse.com/show_bug.cgi?id=1147412#c11
--- Comment #11 from Coly Li
(In reply to Coly Li from comment #8)
I find a bug in bcache btree code which may cause a dirty btree node being lack of journal protection from a power failure. The result might be an inconsistent and broken btree node, and trigger a similar panic as the port listed.
Now I am working on a fix and will test it.
Coly Li
P.S the fix looks like this,
commit d48baef4543246ef910b262959ae89c5a6d197f7 Author: Coly Li
Date: Wed Sep 25 22:16:33 2019 +0800 bcache: fix fifo index swapping condition in journal_pin_cmp()
This patch is invalid, the original code is correct. So far I don't find any suspicious place from the code.
Now I am doing bcache backport for a series fixes, let's see weather these fixes may be a bit helpful.
I guess, it is because the in-memory btree node was not flushed in time, and the on-SSD btree node got corrupted. This is just my guess, and let me explain how I think in this way. Before v5.3, there is a problem that when I/O is busy, it is possible a race will happy when flushing a dirty btree node onto the SSD. If this happens, undefined behavior will happen. This bug was fixed in following 2 patches, commit 91be66e1318f ("bcache: performance improvement for btree_flush_write()") commit 2aa8c529387c (“bcache: avoid unnecessary btree nodes flushing in btree_flush_write()") My suggestion is, try to backup the data, or make sure the data on backing device is consistent. Then update to latest tumbleweed kernel or Linux stable kernel, then re-make the bcache devices. This is only my guess, so far this is the only related clue shows up in my brain. Coly Li -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com