On Wed, Aug 19, 2015 at 6:44 PM, Jonathan Panozzo <j...@lime-technology.com> wrote: > Hello btrfs mailing list! > > I have a two questions regarding the use of the NOCOW bit and how this > affects scrub and snapshots. > > Question 1: If I apply the NOCOW attribute to a file or directory, how does > that affect my ability to run btrfs scrub?
nodatacow includes nodatasum and no compression. So it means these files are presently immune from scrub check and repair so long as it's based on checksums. I don't know if raid56 scrub compares to parity and recomputes parity (assumes data is correct), absent checksums, which would be similar to how md raid 56 does it. > Question 2: If I apply the NOCOW attribute recursively to a btrfs subvolume > I create, There's no such thing as recursive application of this xattr to files. Recursivity would only apply to directories (and probably nested subvolumes but I haven't tested it). > then take a snapshot of that subvolume, make changes to the files in the > snapshot, and then make changes to the files in the subvolume, does this > cause data in the snapshot to be corrupted? It doesn’t appear so, but I’m > confused how it’s not if COW has been disabled using the NOCOW bit. http://www.spinics.net/lists/linux-btrfs/msg31342.html Any changes to a snapshot nocow file are cow. Any additional changes to those extents are nocow until those extents are likewise snapshot (by the file being reflink copied or subvolume is snapshot). So if the change to an extent will only affect a particular instance of a nocow file, the write is overwrite (nocow). If it's a shared extent, then the write is cow, and that extent is (initially) not shared and thus additional writes are nocow. -- Chris Murphy -- 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
