From: Andrei Borzenkov <arvidjaar@gmail.com>
To: john terragon <jterragon@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: inconsistent send/receive behavior
Date: Sun, 1 Aug 2021 10:57:39 +0300 [thread overview]
Message-ID: <928b6090-b495-95fe-8b8c-a33293550e45@gmail.com> (raw)
In-Reply-To: <CANg_oxz7cDq4J4EPWb58A9Kz_Rb9W279pRW=j3OTRvps-aLvzw@mail.gmail.com>
On 01.08.2021 10:19, john terragon wrote:
> Hi.
> Let's consider the following send/receive example
>
> -two btrfs FS /btrfsA /btrfsB
> -one subvol vol in /btrfsA
> -btrfs sub snap -r vol vol1_RO
> -btrfs send /btrfsA/vol1_RO | btrfs receive /btrfsB
> -then, in /btrfsB:
> btrfs sub snap vol1_RO vol
> -do some work on /btrfsB/vol
> -then in /btrfsB:
> btrfs sub snap -r vol vol2_RO
> -then from /btrfsB:
> -btrfs send -p vol1_RO vol2_RO | btrfs receive /btrfsA
>
> So, the initial seeding is from btrfsA to btrfsB and then there is an
> incremental send "in reverse" from btrfsB ro btrfsA.
>
> Is something like this supposed to work?
>
No. /btrfsB/vol does not exist on /btrfsA, so any reference to
/btrfsB/vol cannot be resolved on /btrfsA.
> Because I've got cases in which it seems to work (no error or data
> loss that I can see) and cases in which the "reverse incremental send"
> does send stuff back for a while and it creates the vol2_RO subvolume
> but then it ends up throwing an
>
> ERROR: clone: did not find source subvol
>
> So, it does not say that immediately at the start. It seemingly does
> all the work before complaining.
> And the resulting vol2_RO in btrfsA seems to be OK.
> du /brtfsA/vol2_RO reports a size that's close to the one of /brtfsB/vol2_RO.
> And df reports that /brtfsA/vol2_RO seems to be using a fraction of
> its reported size by du.
>
> So, at the very least, even if this "reverse incremental send" is not
> supposed to work in btrfs, there is inconsistent behavior of the FS
> and/or the btrfs tool.
>
btrfs send builds stream incrementally. It does not really know that it
will need reference to /btrfsB/vol until it actually sees this part. So
btrfs receive cannot verify whether it will fail. It processes input
stream as far as it can - this will be data unchanged between
/btrfsB/vol1_RO and /btrfsB/vol.
prev parent reply other threads:[~2021-08-01 7:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-01 7:19 inconsistent send/receive behavior john terragon
2021-08-01 7:57 ` Andrei Borzenkov [this message]
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=928b6090-b495-95fe-8b8c-a33293550e45@gmail.com \
--to=arvidjaar@gmail.com \
--cc=jterragon@gmail.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).