On 11/26/2014 04:20 PM, Roman Mamedov wrote:
On Wed, 26 Nov 2014 16:00:23 -0800
Robert White <rwh...@pobox.com> wrote:
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.
Well, this FS is coming from being Ext4 for years, so it's not worse off now
than it was before. And anyways the main feature that I wanted were snapshots.
Given that you wont be able to scrub the data and BTRFS is usable but
still a little brittle, it might be a little worse off than you think.
Plus if you ever find yourself in need of balancing you've tossed out
one level of data integrity right here at the start.
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.
Ha, indeed I can't. Maybe there should be a way to generate checksums without
rewriting files, just via reading them, then calculating and writing checksum
to metadata.
That problem would be "computationally hard" because you'd have to
verify that no other file was using that extent before you put that
extent under control of the csum machinery, otherwise you might break
later break the COW promise when the file that knows those blocks by
their checksum changes the contents out from underneath the other
references.
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.
The nodatasum flag also isn't accessible via chattr, is it?
It is not. NODATASUM and NODATACOW are private features. The linux
kernel has no general concept of data checksums. The BTRFS guys mapped
the NODATACOW attribute onto the existing lsattr/chattr bit because it
was defined for another file system long ago.
You'll also find that you can not set or clear the C attr on a file in a
BTRFS unless its size is zero. So all your files now have the C
attribute more-or-less forever. Only a normal copy operation (e.g.
allocating new extents and writing the data into them wiht the checksum
feature in force) will change that.
--
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
