All of lore.kernel.org
 help / color / mirror / Atom feed
From: Remi Gauvin <remi@georgianit.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Incremental receive completes succesfully despite missing files
Date: Tue, 22 Jan 2019 01:00:13 -0500	[thread overview]
Message-ID: <f3075aa9-d475-43cb-45eb-e02acb1d2868@georgianit.com> (raw)
In-Reply-To: <CAJCQCtScPtJ=agTJbunPG9GT4hQg5VQWMOEM_JAyLseNKraqNw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 919 bytes --]

On 2019-01-21 11:54 p.m., Chris Murphy wrote:
#
> 
> I expect the last command to fail because 1.ro1 is not the parent of
> 2.ro2. The command completes, and 2.ro2 is on the destination, and at
> least in this simple example it contains the expected files. However
> 'btrfs show' indicates that the "parent UUID" of 2.ro2 is the "UUID"
> of 1.ro1, which is definitely wrong. So it's a legit bug, not just a
> cosmetic problem due to lack of error checking.
>


This is, as far as I understand, exactly how it's *supposed* to work, at
least, as documented.  The only relationship needed between a "parent"
snapshot, and the snapshot you're sending, is that the parent already
exists on the destination.  Your example would be completely
counter-productive, since there is no data shared between the two, but
perfectly legitimate.  1.ro1 is the parent of 2.ro2 because *you
explicitly told it to*.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2019-01-22  6:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-20 10:25 Incremental receive completes succesfully despite missing files Dennis K
2019-01-20 14:04 ` Andrei Borzenkov
2019-01-21 22:23 ` Chris Murphy
2019-01-22  4:36   ` Chris Murphy
2019-01-22  4:54   ` Chris Murphy
2019-01-22  6:00     ` Remi Gauvin [this message]
2019-01-22  6:28       ` Chris Murphy
2019-01-22 17:57         ` Andrei Borzenkov
2019-01-22 19:37           ` Chris Murphy
2019-01-22 19:45             ` Hugo Mills
2019-01-23 10:44   ` Dennis Katsonis
2019-01-23 11:25     ` Andrei Borzenkov
2019-01-23 13:52       ` Dennis Katsonis
2019-01-23 18:17         ` Andrei Borzenkov
2019-01-23 15:25       ` Hans van Kranenburg
2019-01-23 15:32         ` Nikolay Borisov
2019-01-23 16:23           ` Hans van Kranenburg
2019-01-24 10:40             ` Dennis K
2019-01-24 17:22               ` Chris Murphy
2019-01-26  2:43                 ` Dennis Katsonis
2019-01-26 23:09                   ` Chris Murphy
2019-01-27  1:58                     ` Dennis Katsonis
2019-01-23 15:40         ` Remi Gauvin
2019-01-23 16:59           ` Hans van Kranenburg

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=f3075aa9-d475-43cb-45eb-e02acb1d2868@georgianit.com \
    --to=remi@georgianit.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.