Rich Rauenzahn posted on Fri, 05 Jun 2015 15:50:26 -0700 as excerpted: > I get this error occasionally on the same file. I suspect it is some > interaction between vmware server and btrfs. Besides this error, I have > no ill effects. > > Is this a known issue? Is it something that ought to be investigated to > improve btrfs? > > I might be able to help find the right folks at vmware... > > Rich > > Fri Jun 5 15:43:41 2015: Jun 5 15:43:41 tendo kernel: BTRFS: checksum > error at logical 2253263028224 on dev /dev/sde1, sector 2382346400, root > 257, inode 610942, offset 908943360, length 4096, links 1 (path: > VMs/Ubuntu 64-bit/564dc367-07ae-10b5-bff0-8762c109606c.vmem) Non-dev list-regular answer... The problem in /general/ (not sure about the details) is known and has been seen before on, among other things, VMs running MS Windows. What's very likely happening is that inside the kernel, vmware is sending btrfs data to be saved using direct-IO (normal cached access doesn't normally have this issue as the rules are stricter), but then modifying it "in flight", after sending the pointer and after btrfs has calculated or is calculating the checksum, but before btrfs has fully saved it to the filesystem. The correct fix of course is "don't do that", don't modify the data after it has been handed to btrfs, but... One possible user-side workaround is to ensure that the files in question are set NOCOW, chattr +C. This turns off copy-on-write, checksumming, and btrfs-side compression, all three, and can have efficiency (fragmentation, etc) benefits for generally large (multi-gig) VM image files as well, tho obviously you lose the benefits of those btrfs features in the process. There is a NOCOW caveat related to btrfs snapshotting, however, as snapshotting locks in place the existing version, such that file blocks effectively become COW1, copied the first time they are modified after the snapshot, after which they are modified in-place again until the next snapshot. For folks doing frequent (more than once a day up to once a minute) snapshotting, this can almost nullify the anti-fragmentation effects of the nocow, depending on how active the file in question is, vs. snapshotting frequency. An additional limitation of btrfs nocow is that it needs set when the file is zero-sized, before it has content, in ordered to take effect properly. The easiest way to ensure this is to set the attribute on the directory in which the nocow files are created, so they inherit the attribute from the directory at creation. For existing files, move them elsewhere and then copy them back after setting the attribute on the dir. The copy back should be handled such that a new file is created, not simply a reflink to the old one. This can be ensured by either moving to a different filesystem (for files upto a few gigs I use my tmpfs-based /tmp for this) so the file /has/ to be recreated, or by cat-ing the file into place using redirection: cat oldfile > newfile. -- 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
