Simone Ferretti posted on Wed, 24 Sep 2014 16:28:35 +0200 as excerpted: > Wed, Sep 24, 2014 at 01:23:32PM +0000, Duncan wrote: >> Simone Ferretti posted on Tue, 23 Sep 2014 14:06:41 +0200 as excerpted: >> >>> we're testing BTRFS on our Debian server. After a lot of operations >>> simulating a RAID1 failure, every time I mount my BTRFS RAID1 volume >>> the kernel logs these messages: >>> >>> [73894.436173] BTRFS: bdev /dev/etherd/e30.20 errs: >>> wr 33036, rd 0, flush 0, corrupt 2806, gen 0 >>> [73894.436181] BTRFS: bdev /dev/etherd/e60.28 errs: >>> wr 244165, rd 0, flush 0, corrupt 1, gen 4 >>> >>> Everything seems to work nice but I'm courious to know what these >>> messages mean (in particular what do "gen" and "corrupt" mean?). >> >> Gen=generation. The generation or transaction-ID (different names for >> the exact same thing) is a monotonically increasing integer that gets >> updated every time a tree update reaches all the way to the superblock. >> In the error context, it means the superblock had one generation number >> but N other blocks had a different (presumably older) generation >> number. >> >> Corrupt is simply the number of blocks where the calculated checksum >> didn't match the recorded checksum, thus indicating an error. >> >> See btrfs device stats -z to reset the numbers to zero (after printing >> them one last time). > > > Thank you much for your quick and illuminating answer. > > I'm wondering if you (or anyone else of course) know if there is btrfs > documentation/papers/anything (besides wiki I did not find anything), in > which it's possible to learn this kind of informations? I've learned it from the list and wiki, and from general background experience and by reading between the lines at times. For the monotonically increasing counts and a zero-out option case, the manpage and help information for btrfs device stats -z, that indicates -z resets counts to zero, implies that they continue to count up otherwise. At one point I think a dev did confirm that on-list, but it's easy enough to read the implication without such confirmation, particularly when it matches observed behavior, as it does. The gen/trans-id thing is in fact covered in the wiki, but at least on the user-wiki side, I believe only in passing as it is mentioned on the btrfs restore page, here: https://btrfs.wiki.kernel.org/index.php/Restore (That is in turn linked from the problem-faq, filesystem won't mount and none of the above helped, is there any hope, entry, as well as from the built-in-tools section of the main page.) Of course people only searching for specific things instead of doing general research before diving head-first into a new filesystem, thus reading most of at least the user section of the wiki, as I did, might miss it. But while it's there, it took an actual problem and trying to actually use restore on my own system before the equivalence of trans-id and generation actually sunk in. The corrupt thing probably came from my previous experience, working with mdraid and its scrub, and with ECC RAM and the related BIOS scrub features. In general, any admin who has worked with (and understood) any sort of checksumming and error detection and correction should have a general idea what's going on there, at least after reading the btrfs-scrub manpage and running it to correct errors a few times, thus seeing how its output matches that of the corresponding stats. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
