new subject for new question On Mon, Sep 18, 2017 at 1:37 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> >> What scenarios can lead to "ERROR: parent determination failed"? > > > > The man page for btrfs-send is reasonably clear on the requirements > > btrfs imposes. If you want to use incremental sends (i.e. the -c or -p > > options) then the specified snapshots must exist on both the source and > > destination. If you don't have a suitable existing snapshot then don't > > use -c or -p and just do a full send. > > > > Well, I do not immediately see why -c must imply incremental send. We > want to reduce amount of data that is transferred, so reuse data from > existing snapshots, but it is really orthogonal to whether we send full > subvolume or just changes since another snapshot. > Starting months ago when I began using btrfs serious, I have been reading, rereading and trying to understand this: FAQ - btrfs Wiki https://btrfs.wiki.kernel.org/index.php/FAQ#What_is_the_difference_between_-c_and_-p_in_send.3F The comment above suddenly gives me another clue... However, I still don't understand terms like "clone range ioctl", although I can guess it is something like a hard link. Would it be correct to say the following? 1. "-c" causes (appropriate) files in the newly transferred snapshot to be "hard linked" to existing files in another snapshot on the destination. Doesn't "-p" do something equivalent though? 2. The -c and -p options can be used together or individually. Questions: If "-c" "will send all of the metadata of @B.1, but will leave out the data for @B.1/bigfile, because it's already in the backups filesystem, and can be reflinked from there" what will -p do in contrast? Will "-p" not send all the metadata? Will "-p" also leave out the data for @B.1/bigfile, when it's also already in the backups? What would make me choose one of these options over the other? I still struggle to see the difference. -- 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
