RE: Questions on use of NOCOW impact to subvolumes and snapshots

[Zhao Lei <zhaolei@cn.fujitsu.com>]

Hi, Jonathan Panozzo,

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org
> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Chris Murphy
> Sent: Thursday, August 20, 2015 9:56 AM
> To: Jonathan Panozzo <jonp@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
> <jonp@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 majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html