On 11/26/2014 03:33 PM, Roman Mamedov wrote:
On Wed, 26 Nov 2014 15:18:26 -0800
Robert White <rwh...@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".
--
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
