Thread (17 messages) 17 messages, 3 authors, 2016-03-03

Re: BUG: drivers/md/bcache/writeback.c:237

From: Eric Wheeler <hidden>
Date: 2016-02-26 04:56:27

On Thu, 25 Feb 2016, Marc MERLIN wrote:
On Thu, Feb 25, 2016 at 06:46:33PM -0800, Marc MERLIN wrote:
quoted
Given that, I'm happy to run code that spits out diagostics, but probably
not something that will attempt to write an outdated cache on a filesytem
that's already ahead.
Or does bcache understand that the backing device is ahead already and the
cache should just be discarded?
Yeah, sorry, I did forget to mention that I did a force run on the 
backing device so that I could get to its data. In doing so, I probably 
invalidated options to try and reply the cache to see if things would 
crash, or not, sorry about that.

Now, if I try to make the cache available again, will the code be smart and
not try to reapply a stale cache (never mind that it's probably corrupted in
addition to being old?)
According to Documentation/bcache.txt:
	"" If you're booting up and your cache device is gone and never
	coming back, you can force run the backing device:
	  echo 1 > /sys/block/sdb/bcache/running
	[...]
	The backing device will still use that cache set if it shows up
	in the future, but all the cached data will be invalidated.  ""

So it seems that you are safe.  (It would be interesting to know how it 
invalidates the cache.  Maybe bumps the Set UUID?  Not sure.)

This is what the patch does:

The code in super.c would do what bcache has always done in your kernel, 
except that it holds the writeback_lock to prevent a writeback kthread 
race before initialization is complete.  All that does is delay the 
writeback thread slightly.  If that fixes it, then it is a trivial patch 
from which everyone may benefit.

The code in writeback.c just jumps to the OOM case instead of bugging. If 
it does meet the printk(KERN_WARNING)+dump_stack() condition, then it 
might give us useful data to troubleshoot from.  I think this is quite 
safe since the OOM path just sleeps the kthread until the next writeback 
is scheduled and will try again.  If it dump_stack()'s every scheduled 
writeback interval, then something is seriously wrong somewhere else.

-Eric


Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help