Re: Can't cp --reflink files on a Ext4-converted FS w/o checksums

[Robert White <rwhite@pobox.com>]

On 11/26/2014 03:33 PM, Roman Mamedov wrote:
> On Wed, 26 Nov 2014 15:18:26 -0800
> Robert White <rwhite@pobox.com> wrote:
>
>> So you _could_ reflink the file but you'd have to do it to another file
>> with no data checksums -- which basically means a NOCOW file, or
>> mounting with nodatasum while you do the reflink, but now you have more
>> problem files.
>
> Bingo!!! A cp --reflink to a destination that's been made chattr +C prior to
> that, works perfectly.
>
> My goal was to convert regular top-level directories into subvolumes (for
> further snapshotting). With that trick, I've been able to do that now w/o
> issues.
>
> $ mv Music Music.orig
> $ sudo btrfs sub create Music
> Create subvolume './Music'
> $ sudo chattr +C Music
> $ sudo cp -a --reflink Music.orig/* Music/
> $
>
> Finished with no rewriting necessary. After that I recursively-removed the +C
> attribute from all newly reflinked files, and cp --reflink as well as
> snapshotting of those works fine.
>
> Thanks for the idea. :)
>

Uh... you may _still_ have no checksums on any of those data extents. 
They are not going to come back until you write them to a normal file 
with a normal copy. So you may be lacking most of the data validation 
features of this filesystem. For instance you can, and always could, 
snapshot a NODATACOW/NODATASUM file just fine (I call it 1COW mode).

Setting NODATACOW sets NODATASUM...

Clearing NODATACOW does _not_ clear NODATASUM (at least not on a 
non-empty file) as near as I can tell, so that directory hierarchy and 
its subsequent snapshots is likely "less safe" than you think.

You might want to go experiment. Make another new subvol (or at least a 
directory in a directory/root/subvol that never had the +C attribute 
set) and see if you can cp --reflink any of these files into that 
subdirectory without repeating the +C trick.

Basically scrubbing and mirroring and "sending" your Music folder is an 
unprotected and unverified operation the way you've done this (if my 
reading of the code is correct).

You _really_ might be better off spending the time and doing the copy to 
a normal directory.

For instance without checksums if you "btrfs scrub" your volume it will 
read the file but it can't know if the file got corrupted, it can only 
tell you if you if the disk read completed without error. (there's a 
whole degenerate/simplified path in the code for scrubbing un-summed files).

So seriously, you might be "Saving yourself time" right into a future 
data loss.

Take this as a "you've been warned".