Robert White posted on Wed, 26 Nov 2014 15:18:26 -0800 as excerpted:
I also don't see anything in the code that says this ioctl will create
the checksums for the selected file so you may have to do the copy you
tried to avoid.
Note that btrfs check has an --init-csum-tree switch. In a new
On 11/27/2014 01:27 AM, Duncan wrote:
Robert White posted on Wed, 26 Nov 2014 15:18:26 -0800 as excerpted:
I also don't see anything in the code that says this ioctl will create
the checksums for the selected file so you may have to do the copy you
tried to avoid.
Note that btrfs check has an
On 11/26/2014 11:55 AM, Roman Mamedov wrote:
Is there really a good reason to stop these files without checksums from being
cloneable? It's not like they have the noCoW attribute, so I'd assume any new
write to these files would cause a CoW and proper checksums for all new blocks
anyways.
The
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
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
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
On 11/26/2014 03:33 PM, Roman Mamedov wrote:
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.
I did some double checking and I think you'll find that if you
On Wed, 26 Nov 2014 16:20:44 -0800
Robert White rwh...@pobox.com wrote:
I did some double checking and I think you'll find that if you lsattr
those files they still have the C (NoCOW) attribute, which also means
they are still unsummed.
Indeed, I looked at the top level only, which had just
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
On 11/26/2014 04:28 PM, Roman Mamedov wrote:
On Wed, 26 Nov 2014 16:20:44 -0800
Robert White rwh...@pobox.com wrote:
(Trying to clear the NOCOW attribute on a file in BTRFS is _silently_
ignored as invalid. That recursive removal only changed the directories.)
And the chattr command even
On 11/26/2014 04:31 PM, Robert White wrote:
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:
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
On Thu, Nov 27, 2014 at 12:55:27AM +0500, Roman Mamedov wrote:
Hello,
I used btrfs-convert to switch my FS from Ext4 to Btrfs. As it was a rather
large 10 TB filesystem, to save on the conversion time, I used the -d,
disable data checksum option of btrfs-convert.
Turns out now I can't cp
12 matches
Mail list logo
