Adam Borowski posted on Sun, 25 Sep 2016 01:50:14 +0200 as excerpted: > On Sun, Sep 25, 2016 at 02:25:32AM +0300, Alexander Tomokhov wrote: >> Ok, so data checksumming does not remain for newly created empty files >> with No_COW attribute. I think it's an important trait of Btrfs >> behavior and should be added to wiki. So that users are informed that >> disabling CoW on a per-file basis also loses checksum correctness of >> such file. > > Actually, it disables pretty much all btrfs features except for... CoW. > > You lose: > * checksums > * compression > * safety against power loss (torn writes, etc) > * transactions (not that anyone uses them...) > * etc > But, CoW is still there. > Try it: make a subvolume, create a > FS_NO_COW file (preferably one big enough), snapshot the subvolume, > filefrag -v both copies. Write to one of them, changing only a part of > file. Wait for writeout, filefrag -v them again. That's because snapshots depend on COW. If you don't snapshot the file (or otherwise create additional reflinks to it, using cp --reflink=always, for instance), it'll be NOCOW. But because snapshots (and other forms of multiple reflink) depend on COW, taking a snapshot (or otherwise multi- reflinking) and then writing to one copy forces what has been referred to on this list as COW1, a single COW to break the multi-reflink. However, COW1 doesn't change the NOCOW attribute, and further writes to the same block of the NOCOW file will overwrite the now-current block, instead of COWING it... until the next snapshot (or another multi-reflink operation) locks it too in place, of course, after which another COW1 will be required. Which means otherwise NOCOW files that are both repeatedly overwritten and repeatedly snapshotted, with both happening at about the same rate or snapshots happening more frequently than rewrites, will tend to fragment almost as fast as if they hadn't been set NOCOW in the first place. So NOCOW still has an effect -- as long as rewrites are coming in more frequently than snapshots. However, if the file is repeatedly snapshotted at the same or faster rate than it is rewritten, all those COW1s due to the repeated snapshotting will pretty effectively nullify the NOCOW setting, even if it otherwise remains valid. The other alternative, of course, is to avoid snapshotting your NOCOW files (which of course means losing send/receive, since send requires a read-only snapshot). You can choose one or the other, but can't have both without one, NOCOW, yielding to the other. -- 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
