Austin S Hemmelgarn posted on Tue, 20 Oct 2015 15:48:07 -0400 as excerpted:
> FWIW, my assessment is based on some testing I did a while back (kernel > 3.14 IIRC) using a VM. The (significantly summarized of course) > procedure I used was: > 1. Create a basic minimalistic Linux system in a VM (in my case, I just > used a stage3 tarball for Gentoo, with a paravirtuaized Xen domain) > using BTRFS as the root filesystem with a raid1 setup. Make sure and > verify that it actually boots. > 2. Shutdown the VM, use btrfs-progs on the host to find the physical > location of an arbitrary file (ideally one that is not touched at all > during the boot process, IIRC, I think I used one of the e2fsprogs > binaries), and then intentionally clear the CRC in one of the copies of > a block from the file. > 3. Boot the VM, read the file. > 4. Shutdown the VM again. > 5. Verify whether the file block you cleared the checksum on has a valid > checksum now. > > I repeated this more than a dozen times using different files and > different methods of reading the file, and each time the CRC I had > cleared was untouched. Based on this, unless BTRFS does some kind of > deferred re-write that doesn't get forced during a clean unmount of the > FS, I felt it was relatively safe to conclude that it did not > automatically fix corrupted blocks. I did not however, test corrupting > the block itself instead of the checksum, but I doubt that that would > impact anything in this case. AFAIK: 1) It would only run into the corruption if the raid1 read-scheduler picked that copy based on the even/odd of the requesting PID. However, statistically that should be a 50% hit rate and if you tested more than a dozen times, you'd have quite the luck to fail to hit it on at least /one/ of them. 2) (Based on what I understood from the discussion of btrfs check's init- csum-tree patches a couple cycles ago, before which it was clearing but not reinitializing...) Btrfs interprets missing checksums differently than invalid checksums. Would your "cleared" CRC be interpreted as invalid or missing? If missing, AFAIK it would leave it missing. In which case corrupting the data block itself would indeed have had a different result than "clearing" the csum, tho simply corrupting the csum should have resulted in an update. However, by actually testing you've gone farther than I have, and pending further info to the contrary, I'll yield to that, changing my own thoughts on the matter as well, to "I formerly thought... but someone's testing some versions ago anyway suggested otherwise, so being too lazy to actually do my own testing, I'll cautiously agree with the results of his." =:^) Thanks. I'd rather find out I was wrong, than not find out! =:^) -- 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
