On Tue, Sep 19, 2017 at 1:24 PM, Graham Cobb <g.bt...@cobb.uk.net> wrote: > On 19/09/17 01:41, Dave wrote: >> Would it be correct to say the following? > > Like Duncan, I am just a user, and I haven't checked the code. I > recommend Duncan's explanation, but in case you are looking for > something simpler, how about thinking with the following analogy... > > Think of -p as like doing an incremental backup: it tells send to just > send the instructions for the changes to get from the "parent" subvolume > to the current subvolume. Without -p it is like a full backup: > everything in the current subvolume is sent. > > -c is different:
It is not really different - it is extra. You have -p and optionally -c which modifies its behavior. > it says "and by the way, these files also already exist > on the destination so they might be useful to skip actually sending some > of the file contents". Imagine that whenever a file content is about to > be sent (whether incremental or full), btrfs-send checks to see if the > data is in one of the -c subvolumes and, if it is, it sends "get the > data by reflinking to this file over here" instead of sending the data > itself. -c is really just an optimisation to save sending data if you > know the data is already available somewhere else on the destination. > > Be aware that this is really just an analogy (like "hard linking" is an > analogy for reflinking using the clone range ioctl). Duncan's email > provides more real details. > > In particular, this analogy doesn't explain the original questioner's > problem. In the analogy, -c might work without the files actually being > present on the source (as long as they are on the destination). But, in > reality, because the underlying mechanism is extent range cloning, the > files have to be present on **both** the source and the destination in > order for btrfs-send to work out what commands to send. > Yes. Decision whether to send full data or reflink is taken on source, so data must be present on source. > By the way, like Duncan, I was surprised that the man page suggests that > -c without -p causes one of the clones to be treated as a parent. I have > not checked the code to see if that is actually how it works. > It is. As implemented, -c *requires* parent snapshot, either explicitly via -p option or implicitly. What it does: a) checks that both snapshot to transfer and all snapshots given as arguments to -c have the same parent uuid; b) selects "best match" by comparing how close snapshots from -c option are to parent. As far as I can tell it chooses the oldest snapshot (with minimal difference to the parent) as base (implicit -p). Which implies that "btrfs send -c foo bar" is entirely equivalent to "btrfs send -p foo bar". Which still does not explain why script fails. As mentioned, as snapshots created by snapper should have the same parent uuid, which leaves only possibility of non-existent subvolume, but then script should have failed much earlier. -- 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
