Kai Krakow posted on Sun, 03 Apr 2016 06:02:02 +0200 as excerpted: > No, other files are affected, too. And it looks like those files are > easily affected even when removed and recreated from whatever backup > source.
I've seen you say that several times now, I think. But none of those times has it apparently occurred to you to double-check whether it's the /same/ corruptions every time, or at least, if you checked it, I've not seen it actually /reported/. (Note that I didn't say you didn't report it, only that I've not seen it. A difference there is! =:^) If I'm getting repeated corruptions of something, that's the first thing I'd check, is there some repeating pattern to those corruptions, same place in the file, same "wanted" value (expected), same "got" value, (not expected if it's reporting corruption), etc. Then I'd try different variations like renaming the file, putting it in a different directory with all of the same other files, putting it in a different directory with all different files, putting it in a different directory by itself, putting it in the same directory but in a different subvolume... you get the point. Then I'd try different mount options, with and without compression, with different kinds of compression, with compress-force and with simple compress, with and without autodefrag... I could try it with nocow enabled for the file (note that the file has to be created with nocow before it gets content, for nocow to take effect), tho of course that'll turn off btrfs checksumming, but I could still for instance md5sum the original source and the nocowed test version and see if it tests clean that way. I could try it with nocow on the file but with a bunch of snapshots interwoven with writing changes to the file (obviously this will kill comparison against the original, but I could arrange to write the same changes to the test file on btrfs, and to a control copy of the file on non-btrfs, and then md5sum or whatever compare them). Then, if I had the devices available to do so, I'd try it in a different btrfs of the same layout (same redundancy mode and number of devices), both single and dup mode on a single device, etc. And again if available, I'd try swapping the filesystem to different machines... OK, so trying /all/ the above might be a bit overboard but I think you get the point. Try to find some pattern or common element in the whole thing, and report back the results at least for the "simple" experiments like whether the corruption appears to be the same (same got at the same spot) or different, and whether putting the file in a different subdir or using a different name for it matters at all. =:^) -- 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
