Hi, Jonathan Panozzo, > -----Original Message----- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Chris Murphy > Sent: Thursday, August 20, 2015 9:56 AM > To: Jonathan Panozzo <j...@lime-technology.com>; Btrfs BTRFS > <linux-btrfs@vger.kernel.org> > Subject: Re: Questions on use of NOCOW impact to subvolumes and snapshots > > 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. > In nodatasum case, scrub only try to fix data with io-error.
> 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. > For raid56 with no datasum, in current code: For data strip: If have io error: try to get right data from parity, and writeback For parity strip: check is the parity match data, and try to recovery Thanks Zhaolei > > > 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 -- 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
