From: Robert White <rwhite@pobox.com>
To: Roman Mamedov <rm@romanrm.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Can't cp --reflink files on a Ext4-converted FS w/o checksums
Date: Wed, 26 Nov 2014 16:57:03 -0800 [thread overview]
Message-ID: <547676DF.5080601@pobox.com> (raw)
In-Reply-To: <547670FF.3090407@pobox.com>
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 <rwhite@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 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.
I explained this poorly/incorrectly...
So some guy like yourself converts a file system, or mounts an existing
file system with nodatasum and creates some file. As a result there is a
file called /One that has no checksums on its extents.
Then the guy creates a directory and sets +C on it, and copies the file
into that directory with "cp --reflink /One /d/Two". File /d/Two is a
no-cow file.
Now the guy somes back and decides to put the data checksums onto the
extents of /One.
At this moment everything _looks_ fine.
Then the guy alters the first byte of /d/Two, which modifies the no-cow
file in place.
Now the guy tires to read /One ... what happens? The checksum doesn't
match and the data has changed because of the NOCOW.
(So I think, in practice, the 1COW mechanism prevents this just like it
works for snapshots)
But thats a _lot_ of corner cases that can be solved by telling someone
to copy the file if they want the checksums to be recreated.
e.g. the set of all files and all possibilities gets well into the
"computationally hard" end of the swimming pool.
next prev parent reply other threads:[~2014-11-27 0:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 19:55 Can't cp --reflink files on a Ext4-converted FS w/o checksums Roman Mamedov
2014-11-26 23:18 ` Robert White
2014-11-26 23:33 ` Roman Mamedov
2014-11-27 0:00 ` Robert White
2014-11-27 0:20 ` Roman Mamedov
2014-11-27 0:31 ` Robert White
2014-11-27 0:57 ` Robert White [this message]
2014-11-27 0:20 ` Robert White
2014-11-27 0:28 ` Roman Mamedov
2014-11-27 0:45 ` Robert White
2014-11-27 9:27 ` Duncan
2014-11-28 7:12 ` Robert White
2014-11-27 3:31 ` Liu Bo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=547676DF.5080601@pobox.com \
--to=rwhite@pobox.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).