Linux-BTRFS Archive on
 help / color / Atom feed
From: Chris Murphy <>
To: Eric Mesa <>
Cc: Andrei Borzenkov <>,
	Chris Murphy <>,
	Btrfs BTRFS <>
Subject: Re: Issues with btrfs send/receive with parents
Date: Thu, 13 Jun 2019 21:55:05 -0600
Message-ID: <> (raw)
In-Reply-To: <97541737.v72oTHCfnW@supermario.mushroomkingdom>

On Thu, Jun 13, 2019 at 3:23 PM Eric Mesa <> wrote:
> On Thursday, June 13, 2019 2:26:10 AM EDT Andrei Borzenkov wrote:
> >
> > All your snapshots on source have the same received_uuid (I have no idea
> > how is it possible). If received_uuid exists, it is sent to destination
> > instead of subvolume UUID to identify matching snapshot. All your backup
> > sbapshots on destination also have the same received_uuid which is
> > matched against (received_)UUID of source subvolume. In this case
> > receive command takes the first found subvolume (probably the most
> > recent, i.e. with the smallest generation number). So you send
> > differential stream against one subvolume and this stream is applied to
> > another subvolume which explains the error.
> Yup. Any idea of how to fix?

Maybe 'cp -a --relink' into a new subvolume on the source. It won't
complete immediately like a snapshot. But it'll complete way faster
than a normal data copy. From that point, this new subvolume becomes
"master" where all changes occur, and all the other snapshots are made
from it.

Also, you should do incrementals between the most recent two
snapshots. i.e. the snapshot that follows -p should be the snapshot
most recently successfully received on the destination. That
represents the least amount of increment needed to update the
destination. It will work the way you're doing it now, with -p being
an older snapshot, but you're unnecessarily sending a lot more data
every time.

Chris Murphy

  reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-10 23:56 Eric Mesa
2019-06-11  1:10 ` Chris Murphy
2019-06-11  3:39   ` Andrei Borzenkov
2019-06-11  4:19     ` Eric Mesa
2019-06-12  5:43       ` Andrei Borzenkov
2019-06-12 23:03         ` Eric Mesa
2019-06-12 23:11           ` Eric Mesa
2019-06-13  6:26           ` Andrei Borzenkov
2019-06-13 21:22             ` Eric Mesa
2019-06-14  3:55               ` Chris Murphy [this message]
2019-07-14 20:59                 ` Eric Mesa
2019-06-18  4:15               ` Andrei Borzenkov
2019-06-11  3:47   ` Eric Mesa
2019-06-11  1:11 ` Remi Gauvin

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-BTRFS Archive on

Archives are clonable:
	git clone --mirror linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ \
	public-inbox-index linux-btrfs

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox