Hi, Jonathan Panozzo > -----Original Message----- > From: Jonathan Panozzo [mailto:j...@lime-technology.com] > Sent: Thursday, August 20, 2015 12:41 PM > To: Zhao Lei <zhao...@cn.fujitsu.com> > Cc: Chris Murphy <li...@colorremedies.com>; Btrfs BTRFS > <linux-btrfs@vger.kernel.org> > Subject: Re: Questions on use of NOCOW impact to subvolumes and snapshots > > 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? > Only report some information as: "recover failed".
> 2: Out of curiosity, why is data checksumming tied to COW? > To ensure that the checksum for data is either valid or not exist. Thanks Zhaolei > - 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
