Questions on use of NOCOW impact to subvolumes and snapshots

Questions on use of NOCOW impact to subvolumes and snapshots

[Jonathan Panozzo]

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?

Question 2:  If I apply the NOCOW attribute recursively to a btrfs subvolume I create, 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.

Regards,

Jonathan Panozzo
Lime Technology, Inc.

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

[Chris Murphy]

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. 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

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

[Russell Coker]

On Thu, 20 Aug 2015 11:55:43 AM Chris Murphy wrote:
> > 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.

Linux Software RAID could recreate a mismatched block from RAID-6 parity but 
doesn't do so.  It could be that a block was changed correctly but didn't get 
the parity data written so such "correction" would be reverting a change.  So 
Linux Software RAID only regenerates parity for a scrub and makes both disks 
have the same data for RAID-1.

There's no good solution to these problems without doing the sorts of things 
that WAFL, ZFS, and BTRFS do.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

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

[Chris Murphy]

On Wed, Aug 19, 2015 at 9:43 PM, Russell Coker <russell@coker.com.au> wrote:
> On Thu, 20 Aug 2015 11:55:43 AM Chris Murphy wrote:
>> > 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.
>
> Linux Software RAID could recreate a mismatched block from RAID-6 parity but
> doesn't do so.  It could be that a block was changed correctly but didn't get
> the parity data written so such "correction" would be reverting a change.  So
> Linux Software RAID only regenerates parity for a scrub and makes both disks
> have the same data for RAID-1.

https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf

Discussion starts in section 4 on page 7. The relevant part I'm
confused about is on page 8, " once the faulty drive has been
identified" doesn't clarify a mechanism to determine which data drive
is corrupt. Iti seems without that knowledge, it's not possible to
reconstruct. Further, should there be two corruptions, however
unlikely, reconstruction causes a third corruption. So it's a bit
risky.

In any case though, in normal operation, md raid6 isn't checking
parity. It always assumes the data chunks are valid unless the drive
itself returns a read error. For scrub repair, it assumes data is
correct and writes new parity, which is different than with a raid1
scrub repair where there's something of a random (?) assumption which
mirrored chunk is correct and the other(s) are overwritten. I don't
even know that with n-way mirroring this scrub assumes majority rules.



-- 
Chris Murphy

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

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

On 2015-08-20 12:44, Chris Murphy wrote:
> On Wed, Aug 19, 2015 at 9:43 PM, Russell Coker <russell@coker.com.au> wrote:
>> On Thu, 20 Aug 2015 11:55:43 AM Chris Murphy wrote:
>>>> 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.
>>
>> Linux Software RAID could recreate a mismatched block from RAID-6 parity but
>> doesn't do so.  It could be that a block was changed correctly but didn't get
>> the parity data written so such "correction" would be reverting a change.  So
>> Linux Software RAID only regenerates parity for a scrub and makes both disks
>> have the same data for RAID-1.
>
> https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
>
> Discussion starts in section 4 on page 7. The relevant part I'm
> confused about is on page 8, " once the faulty drive has been
> identified" doesn't clarify a mechanism to determine which data drive
> is corrupt. Iti seems without that knowledge, it's not possible to
> reconstruct. Further, should there be two corruptions, however
> unlikely, reconstruction causes a third corruption. So it's a bit
> risky.
IIUC, the checksumming is done on each part of the block written (in 
which case it's really easy to see which is bogus.  There's also the 
fact that if one of the parities is wrong, but the other isn't, the 
parity block that is wrong is probably faulty (although this isn't a 
100% guarantee).
>
> In any case though, in normal operation, md raid6 isn't checking
> parity. It always assumes the data chunks are valid unless the drive
> itself returns a read error. For scrub repair, it assumes data is
> correct and writes new parity, which is different than with a raid1
> scrub repair where there's something of a random (?) assumption which
> mirrored chunk is correct and the other(s) are overwritten. I don't
> even know that with n-way mirroring this scrub assumes majority rules.
Based on my own testing, it doesn't handle that sanely.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

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

[Zhao Lei]

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

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

[Jonathan Panozzo]

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 <zhaolei@cn.fujitsu.com> wrote:
> 
> 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
> 
> --
> 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

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

[Zhao Lei]

Hi, Jonathan Panozzo

> -----Original Message-----
> From: Jonathan Panozzo [mailto:jonp@lime-technology.com]
> Sent: Thursday, August 20, 2015 12:41 PM
> To: Zhao Lei <zhaolei@cn.fujitsu.com>
> Cc: Chris Murphy <lists@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 <zhaolei@cn.fujitsu.com> wrote:
> >
> > 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
> >
> > --
> > 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

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

[Jonathan Panozzo]

> On Aug 20, 2015, at 1:03 AM, Zhao Lei <zhaolei@cn.fujitsu.com> wrote:
> 
> Hi, Jonathan Panozzo
> 
>> -----Original Message-----
>> From: Jonathan Panozzo [mailto:jonp@lime-technology.com]
>> Sent: Thursday, August 20, 2015 12:41 PM
>> To: Zhao Lei <zhaolei@cn.fujitsu.com>
>> Cc: Chris Murphy <lists@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.

Apologies if my question here wasn’t clear enough.  What I’m wondering is why data checksum is turned off when NOCOW is set.  What ties COW to checksumming?

> 
> Thanks
> Zhaolei
> 
>> - Jon
>> 
>>> On Aug 19, 2015, at 11:09 PM, Zhao Lei <zhaolei@cn.fujitsu.com> wrote:
>>> 
>>> 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
>>> 
>>> --
>>> 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
> 

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

[Zhao Lei]

Hi, Jonathan Panozzo

> -----Original Message-----
> From: Jonathan Panozzo [mailto:jonp@lime-technology.com]
> Sent: Thursday, August 20, 2015 2:13 PM
> To: Zhao Lei <zhaolei@cn.fujitsu.com>
> Cc: Chris Murphy <lists@colorremedies.com>; Btrfs BTRFS
> <linux-btrfs@vger.kernel.org>
> Subject: Re: Questions on use of NOCOW impact to subvolumes and snapshots
> 
> 
> > On Aug 20, 2015, at 1:03 AM, Zhao Lei <zhaolei@cn.fujitsu.com> wrote:
> >
> > Hi, Jonathan Panozzo
> >
> >> -----Original Message-----
> >> From: Jonathan Panozzo [mailto:jonp@lime-technology.com]
> >> Sent: Thursday, August 20, 2015 12:41 PM
> >> To: Zhao Lei <zhaolei@cn.fujitsu.com>
> >> Cc: Chris Murphy <lists@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.
> 
> Apologies if my question here wasn’t clear enough.  What I’m wondering is
> why data checksum is turned off when NOCOW is set.  What ties COW to
> checksumming?
> 
For data checksum, we need ensure that "the checksum is always valid".
It is to say, the checksum will always consist to data in anytime,
even when the data is in writing(changing).

Above requirement is implemented by cow.
So, datachecksum need cow.

Thanks
Zhaolei

> >
> > Thanks
> > Zhaolei
> >
> >> - Jon
> >>
> >>> On Aug 19, 2015, at 11:09 PM, Zhao Lei <zhaolei@cn.fujitsu.com> wrote:
> >>>
> >>> 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
> >>>
> >>> --
> >>> 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
> >

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

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

On 2015-08-20 00:40, Jonathan Panozzo wrote:
> 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?
Yes.
>
> 2:  Out of curiosity, why is data checksumming tied to COW?
There's no safe way to sanely handle checksumming without COW, because 
there is no way (at least on current hardware) to ensure that the data 
block and the checksums both get written at the exact same time, and 
that one of the writes aborting will cause the other too do so as well. 
  In-place compression is disabled for nodatasum files for essentially 
the same reason (although compression can cause much worse data loss 
than a failed checksum).




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

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

[Russell Coker]

On Thu, 20 Aug 2015 10:09:26 PM Austin S Hemmelgarn wrote:
> > 2:  Out of curiosity, why is data checksumming tied to COW?
> 
> There's no safe way to sanely handle checksumming without COW, because
> there is no way (at least on current hardware) to ensure that the data
> block and the checksums both get written at the exact same time, and
> that one of the writes aborting will cause the other too do so as well.
>   In-place compression is disabled for nodatasum files for essentially
> the same reason (although compression can cause much worse data loss
> than a failed checksum).

A journaling filesystem could have checksums on data blocks.  If Ext4 was 
modified to have checksums it would do that.

But given that a major feature of BTRFS is snapshots it doesn't make much 
sense to implement a separate way of managing checksums.  I think that ZIL is 
the correct way of solving these problems.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/