All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas D Steeves <sten@debian.org>
To: Andy Smith <andy@strugglers.net>
Cc: Andrei Borzenkov <arvidjaar@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Copying a btrfs filesystem from one host to another, reflinks, compression
Date: Fri, 27 Dec 2024 15:21:17 -0700	[thread overview]
Message-ID: <87y10022ea.fsf@gmail.com> (raw)
In-Reply-To: <Z1ErVJYZJKMiFJb0@mail.bitfolk.com>

Hi Andy,

On Wed, 4 Dec 2024, 23:26 Andy Smith, <andy@strugglers.net> wrote:

> On Thu, Dec 05, 2024 at 07:11:59AM +0300, Andrei Borzenkov wrote:
> > 05.12.2024 01:24, Andy Smith wrote:
> > > rsync or tar | ssh | tar are not going to handle reflinked files,
> > > are they?
> > >
> > > Should I be using btrfs-send?
> >
> > btrfs send/receive has better support for sharing data between files,
> yes.
> > It is not guaranteed, that destination will have exactly the same data
> > layout though; btrfs send may decide to send full data instead of sending
> > clone request. I am not sure about exact conditions, IIRC one requirement
> > for cloning is proper alignment.
>
> Hmm. I don't mind if the destination has a  bit of a different layout
> but I would not like if a significant number of the regions on the
> source got deduplicated…
>
> I guess I will have to try it and see what happens (time-consuming,
> given the size).
>
> If it expands too much
> > > Source host's kernel is 5.10.0-32; btrfs-progs v5.10.1 (Debian 11).
> > > Destination would be Debian 12 so kernel 6.1.0-28 and btrfs-progs v6.2
> > >
> >
> > According to man btrfs-send, --compressed-data should preserve
> compression.
>
> Looks like I would have to install a newer btrfs-progs on the sender as
> I read in:
>

https://backports.debian.org/Instructions/

You can use bullseye-backports on the sender to install a 6.x kernel and
btrfs-progs versions from bookworm (Debian 12).

Whether it works or not, please consider writing to the backports mailing
list, and maybe CC Alexander Writ, because you have a compelling use case
for keeping at least a subset of oldstable backports active longer than
they're usually kept active.

I hope these backports save you some time!
Regards,
Nicholas

      reply	other threads:[~2024-12-27 22:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04 22:24 Copying a btrfs filesystem from one host to another, reflinks, compression Andy Smith
2024-12-05  4:11 ` Andrei Borzenkov
2024-12-05  4:25   ` Andy Smith
2024-12-27 22:21     ` Nicholas D Steeves [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=87y10022ea.fsf@gmail.com \
    --to=sten@debian.org \
    --cc=andy@strugglers.net \
    --cc=arvidjaar@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 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.