Chris Murphy posted on Tue, 24 Sep 2013 22:34:20 -0600 as excerpted: > However, even after deleting all corrupt journal files, and a subsequent > scrub reporting no errors, on each reboot (and mount of the filesystem) > I get: > > [ 3.646448] btrfs: bdev /dev/sda6 errs: wr 0, rd 0, flush 0, corrupt > 17, gen 0 > > So somehow the corrupt counter isn't being reset?
AFAIK, it's deliberate that errors aren't reset automatically so there's some historical record and it's possible to see if they start to accumulate. But there is of course a manual reset available, should a sysadmin wish to use it... <quick lookup, quoting the commandline help output> ... btrfs device stats [-z] <path>|<device> Show current device IO stats. -z to reset stats afterwards. What the (brief) help output doesn't say but the (longer) manpage does... for multi-device filesystems <path> will list (and zero with -z) stats for all devices (listing one device's stats after another) composing the filesystem, <device> will list/zero them for just that single component device. The -r does reset things here. (FWIW I have a device that's occasionally slow enough to stabilize on power-up, that at least with 3.11, btrfs would occasionally drop it on resume after a suspend, forcing a hard reboot soon after, with resulting corruption. Fortunately I'm running raid1 mode both data/metadata, and a scrub has always fixed things as verified by a further scrub and balance, but the stats errors of course stuck around until I did a -r/reset. So I have personal knowledge of this one. But with last nite's 3.12-rc2 git kernel pull and build I changed the kernel commandline option I was using from rootdelay=N to rootwait, and between that and the btrfs fixes in 3.12, I'm hoping I won't see that problem again. I guess I'll find out over the coming couple weeks or so, at which I'll declare the issue gone if I've not seen it again.) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
