linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "André Malm" <admin@sheepa.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs send with parent different size depending on source of files.
Date: Tue, 19 Feb 2019 00:58:53 +0100	[thread overview]
Message-ID: <fec70b89-90ee-20b9-d47a-ae1be31361fc@sheepa.org> (raw)
In-Reply-To: <CAJCQCtRvxpai3Cs+588T+QjYJbJSs2NE=nzkZ90FY41M9peXog@mail.gmail.com>

I assume i would have to use rsync (with --inplace possibly) to keep the 
master volume in sync between machines?

Say for example I have a (large) file on master, on machine A, I cp 
reflink it to a child subvolume. I then send -p child subvolume to 
remote machine B (which already have the master volume). Then i change 
parts of the file on the master of machine A. I then rsync (?) the 
master volume so its the same across the machines. Can I then later send 
-p the child volume, either back to the original machine (A) or to a 3rd 
machine (C) given that the master volumes are synced?

About the efficiency I'm not planning to remove large amounts of data 
that is used by child subvolumes (although some will be updated). But 
given the unpredictability of what files will be used by child 
subvolumes i might remove large unused amounts of data.

On 2019-02-19 00:49, Chris Murphy wrote:
> On Mon, Feb 18, 2019 at 3:58 PM André Malm <admin@sheepa.org> wrote:
>> Ok, but I don't want to keep old snapshots of the child volumes. Only
>> the latest and then diffing it in regards to the master. Would that be
>> possible?
> In order to do an incremental send/receive you need to have the -p
> snapshot on both source and destination file systems. You can delete
> snapshots older than that.
>
> I still don't understand why you're diffing in regards to master. It's
> going to be inherently inefficient because you've said a large amount
> of the contents of master aren't important; but by using it as the -p
> reference snapshot, you're asking send to do a comparison that
> includes a lot of metadata you don't care about. It's more efficient
> to diff the incremental snapshots of the changing state of
> "childofmaster" subvolume.
>



  reply	other threads:[~2019-02-18 23:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 11:37 Btrfs send with parent different size depending on source of files André Malm
2019-02-14 22:37 ` Chris Murphy
2019-02-15  4:00   ` Remi Gauvin
2019-02-15 18:38     ` Chris Murphy
2019-02-15 18:56       ` Remi Gauvin
2019-02-16 20:10         ` Andrei Borzenkov
2019-02-15 17:45   ` Andrei Borzenkov
2019-02-15 19:11     ` Chris Murphy
2019-02-16 20:26       ` Andrei Borzenkov
2019-02-16 20:32         ` Andrei Borzenkov
2019-02-18 18:00         ` Chris Murphy
2019-02-15 19:29 ` Remi Gauvin
2019-02-15 19:41   ` Remi Gauvin
2019-02-16 20:08 ` Andrei Borzenkov
2019-02-17  3:11   ` Remi Gauvin
2019-02-18 13:05     ` André Malm
2019-02-18 18:06       ` Chris Murphy
2019-02-18 19:58         ` André Malm
2019-02-18 20:59           ` Graham Cobb
2019-02-18 21:22           ` Chris Murphy
2019-02-18 21:36             ` André Malm
2019-02-18 22:28               ` Chris Murphy
2019-02-18 22:58                 ` André Malm
2019-02-18 23:49                   ` Chris Murphy
2019-02-18 23:58                     ` André Malm [this message]
2019-02-19  0:16                       ` Chris Murphy
2019-02-19  0:17                         ` Chris Murphy
2019-02-19  0:28                         ` André Malm
2019-02-19  3:54                           ` Chris Murphy
2019-02-19 12:05                             ` André Malm

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=fec70b89-90ee-20b9-d47a-ae1be31361fc@sheepa.org \
    --to=admin@sheepa.org \
    --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 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).