Copying a btrfs filesystem from one host to another, reflinks, compression

Copying a btrfs filesystem from one host to another, reflinks, compression

[Andy Smith]

Hi,

I need to copy a pretty large filesystem from one host to another.
What's the best way to do it?

The source filesystem has a single device (redundancy is provided by md
RAID) and uses compression. Destination would be the same. It has a
large number of reflinked files. rsync or tar | ssh | tar are not going
to handle reflinked files, are they?

Should I be using btrfs-send?

There's no subvolumes and no snapshots involved here. Would I just
btrfs-send to a new subvolume and then mount that subvolume as the
"real" filesystem?

Would that preserve compression or would I have to go through and force
recompression of everything?

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

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Copying a btrfs filesystem from one host to another, reflinks, compression

[Andrei Borzenkov]

05.12.2024 01:24, Andy Smith wrote:
> Hi,
> 
> I need to copy a pretty large filesystem from one host to another.
> What's the best way to do it?
> 
> The source filesystem has a single device (redundancy is provided by md
> RAID) and uses compression. Destination would be the same. It has a
> large number of reflinked files. 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.

> There's no subvolumes and no snapshots involved here. Would I just
> btrfs-send to a new subvolume and then mount that subvolume as the
> "real" filesystem?
> 

What do you call "real" filesystem? Any subvolume is just as valid 
subsystem as any other. You can effectively ignore subvolume by 
designating it as default so you do not need to explicitly mention it in 
mount option.

> Would that preserve compression or would I have to go through and force
> recompression of everything?
> 
> 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.

Re: Copying a btrfs filesystem from one host to another, reflinks, compression

[Andy Smith]

Hi Andrei,

Thanks for your reply.

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 I may have to try again with dd.

> > Would that preserve compression or would I have to go through and force
> > recompression of everything?
> > 
> > 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://btrfs.readthedocs.io/en/latest/btrfs-send.html

    --proto <N>

    Version 2 requires at least btrfs-progs 6.0 on both the sender and
    receiver and at least Linux 6.0 on the sender.

    --compressed-data

    This requires protocol version 2 or higher. If --proto was not used,
    then --compressed-data implies --proto 2.

Thanks,
Andy

Re: Copying a btrfs filesystem from one host to another, reflinks, compression

[Nicholas D Steeves]

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