Re: Crash during mount -o degraded, kernel BUG at fs/btrfs/extent_io.c:2044

[Duncan <1i5t5.duncan@cox.net>]

Philip Seeger posted on Sun, 01 Nov 2015 00:36:42 +0100 as excerpted:

> On 10/31/2015 08:18 PM, Philip Seeger wrote:

>> But it looks like there are still some "invisible" errors on this (now
>> empty) filesystem; after rebooting and mounting it, this one error is
>> logged:
>> BTRFS: bdev /dev/sdc errs: wr 0, rd 0, flush 0, corrupt 199313, gen 0
> 
> However, this "invisible" error shows up even with this kernel version.
> 
> So I'm still wondering why this error is happening even after a 
> successful scrub.

That's NOTABUG and not an error, functioning as designed.

Btrfs device error counts are retained until manually reset, and do not 
restart at zero at reboot or with a umount/mount or btrfs module remove/
insert cycle.  This highlights problem devices over time as their error 
counts increase.

So what btrfs is logging to dmesg on mount here, are the historical error 
counts, in this case expected as they were deliberate during your test, 
nearly 200K of them, not one or more new errors.

To have btrfs report these at the CLI, use btrfs device stats.  To zero 
them out, use its -z option.  Then mounting should again report 0 corrupt 
in dmesg once again... until some other error happens, of course. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman