From: Chris Murphy <lists@colorremedies.com>
To: Eric Mesa <eric@ericmesa.com>
Cc: Andrei Borzenkov <arvidjaar@gmail.com>,
Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Issues with btrfs send/receive with parents
Date: Thu, 13 Jun 2019 21:55:05 -0600 [thread overview]
Message-ID: <CAJCQCtRfADiHjG+r-1Gr=1bFw+c-u8-zi+bkLCO=jd5HnxjFDQ@mail.gmail.com> (raw)
In-Reply-To: <97541737.v72oTHCfnW@supermario.mushroomkingdom>
On Thu, Jun 13, 2019 at 3:23 PM Eric Mesa <eric@ericmesa.com> 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
next prev parent reply other threads:[~2019-06-14 3:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 23:56 Issues with btrfs send/receive with parents 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 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='CAJCQCtRfADiHjG+r-1Gr=1bFw+c-u8-zi+bkLCO=jd5HnxjFDQ@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=arvidjaar@gmail.com \
--cc=eric@ericmesa.com \
--cc=linux-btrfs@vger.kernel.org \
/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).