From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: john terragon <jterragon@gmail.com>
Cc: Andrei Borzenkov <arvidjaar@gmail.com>,
sys <system@lechevalier.se>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: hierarchical, tree-like structure of snapshots
Date: Thu, 31 Dec 2020 12:28:13 -0500 [thread overview]
Message-ID: <20201231172812.GS31381@hungrycats.org> (raw)
In-Reply-To: <CANg_oxzP_Dzn89=4W_EZjGQWgB0CYsqyWMHN_3WzwebPVQChfg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
On Thu, Dec 31, 2020 at 05:08:57PM +0100, john terragon wrote:
> On Thu, Dec 31, 2020 at 8:05 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> >
>
> > >
> > > OK, but then could I use Y as parent of the rw snapshot, let's call it
> > > W, in a send?
> >
> > No
> >
>
> Of course I didn't mean to use Y as a parent of W itself but to a
> readonly snapshot of W whenever I want to send it to the second FS.
>
> And I just tried the following steps and they worked:
>
> 1) created subvol X
> 2) created readonly snap Y of X
> 3) sent Y to second FS
> 4) modified X
> 5) created readonly snap X1 of X
> 6) sent -p Y X1 to second FS
> 7) created readwrite snap Y1 of Y
> 8) modified Y1
> 9) created readonly snap Y1_RO of Y1
> 10) sent -p Y Y1_RO to second FS
>
> So, as you can see,
>
> -in 6) I've used the RO snap Y of X as the parent of X1 (and X) to
> send X1 to the second FS
>
> -in 10) I did the opposite, Y is still used as the parent but this
> time I've sent the RO snap of a subvol that is a snap of Y.
>
> So it seems to work both ways
I think your confusion is that you are thinking of these as a tree.
There is no tree, each subvol is an equal peer in the filesystem.
"send -p A B" just walks over subvol A and B and sends a diff of the
parts of B not in A. You can pick any subvol with -p as long as it's
read-only and present on the receiving side. Obviously it's much more
efficient if the two subvols have a lot of shared extents (e.g. because
B and A were both snapshots made at different times of some other subvol
C), but this is not required.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-12-31 17:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-30 16:56 hierarchical, tree-like structure of snapshots john terragon
2020-12-30 17:03 ` john terragon
2020-12-30 17:24 ` sys
2020-12-30 17:39 ` john terragon
2020-12-31 7:05 ` Andrei Borzenkov
2020-12-31 10:00 ` Forza
2020-12-31 16:08 ` john terragon
2020-12-31 17:28 ` Zygo Blaxell [this message]
2020-12-31 18:19 ` john terragon
2020-12-31 19:42 ` Andrei Borzenkov
2020-12-31 20:48 ` john terragon
2020-12-31 21:36 ` Zygo Blaxell
2021-01-01 4:54 ` john terragon
2021-01-01 11:42 ` Andrei Borzenkov
2021-01-01 20:40 ` Andrei Borzenkov
2021-01-01 23:11 ` Zygo Blaxell
2021-01-02 9:25 ` Andrei Borzenkov
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=20201231172812.GS31381@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=arvidjaar@gmail.com \
--cc=jterragon@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=system@lechevalier.se \
/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.