Zhao, Thank you for your response. Two quick follow-up questions:
1: What happens on an unrecoverable data error case? Does the volume get put into read-only mode? 2: Out of curiosity, why is data checksumming tied to COW? - Jon > On Aug 19, 2015, at 11:09 PM, Zhao Lei <zhao...@cn.fujitsu.com> wrote: > > 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 -- 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
