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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
