public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* defrag/compression: will it break reflinks on kernel 4.15.0?
@ 2020-07-27  1:59 Andrew Skretvedt
  2020-07-27  3:45 ` Chris Murphy
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Skretvedt @ 2020-07-27  1:59 UTC (permalink / raw)
  To: linux-btrfs

I've started experimenting with compression on a btrfs filesystem. I'd
like to use 'zstd'.

I'm on linux kernel 4.15.0.

I have a handful of snapshots and I know that if all the reflinks will
be broken, I won't have enough space to keep them all. So the choice I'm
facing is that breaks will happen; I should delete enough snapshots to
ensure space is sufficient, or breaks won't happen and I can leave my
snapshots alone.

Background detail and deeper questions:

I *was* on v4.4 of the userspace tools (ubuntu btrfs-tools package).
I'm *now* on v5.4.1 of these tools (ubuntu btrfs-progs package) via some
careful cherry-picking from a newer release to keep all dependencies
satisfied.

I began by adjusting mount options to include "compress=zstd"; this was
fine. I understand that new writes are getting compressed (if passed by
the compressibility heuristic). But, I understand that to compress
what's already present, I have to issue defrag command(s) with -c. I was
set to go forward and tripped over requesting -czstd, as v4.4 of the
tools didn't support zstd, and I didn't notice. This is what prompted me
to make the tools upgrade.

The manpage "btrfs-filesystem" includes:

> Warning
> Defragmenting with Linux kernel versions < 3.9 or ≥ 3.14-rc2 as well
> as with Linux stable kernel versions ≥ 3.10.31, ≥ 3.12.12 or ≥ 3.13.4
> will break up the reflinks of COW data

I thought I was prepared for this, but now I want to try to be more
certain about what will happen if I start issuing 'defrag -czstd'
commands. Because version 3.x kernels are mentioned several times at
specific subversions, the warnings only apply to newer sub-subversions
of them. I *think* that my 4.15.0 kernel will *not break* reflinks.

Is that correct?

Extra questions:

I see that the userspace tools' version tracks along with the kernel
version. Is it a mistake to use a newer version of the tools than the
running kernel, i.e. should I drop back to v4.15 of the tools?

>From the wiki, I understand that while zstd support was added in kernel
4.14, user-selection of compression level in zstd was not added until
kernel 5.1. So I cannot use mount options like "compress=zstd:3" on
kernel 4.15. BUT, can I yet do "defrag -czstd:3" since I'm running
v5.4.1 tools? Or, must I (should I) just stick to -czstd and accept the
default level it would use. What is that for zstd?

Thanks.

-- 
OpenPGP 0xC6901B2A6C976BB3 (https://keys.openpgp.org)

-- 
OpenPGP 0xC6901B2A6C976BB3 (https://keys.openpgp.org)


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: defrag/compression: will it break reflinks on kernel 4.15.0?
  2020-07-27  1:59 defrag/compression: will it break reflinks on kernel 4.15.0? Andrew Skretvedt
@ 2020-07-27  3:45 ` Chris Murphy
  0 siblings, 0 replies; 2+ messages in thread
From: Chris Murphy @ 2020-07-27  3:45 UTC (permalink / raw)
  To: Andrew Skretvedt; +Cc: Btrfs BTRFS

On Sun, Jul 26, 2020 at 8:05 PM Andrew Skretvedt
<andrew.skretvedt@gmail.com> wrote:
>
> I've started experimenting with compression on a btrfs filesystem. I'd
> like to use 'zstd'.
>
> I'm on linux kernel 4.15.0.
>
> I have a handful of snapshots and I know that if all the reflinks will
> be broken, I won't have enough space to keep them all. So the choice I'm
> facing is that breaks will happen; I should delete enough snapshots to
> ensure space is sufficient, or breaks won't happen and I can leave my
> snapshots alone.

Or just enable compression now, going forward.


> The manpage "btrfs-filesystem" includes:
>
> > Warning
> > Defragmenting with Linux kernel versions < 3.9 or ≥ 3.14-rc2 as well
> > as with Linux stable kernel versions ≥ 3.10.31, ≥ 3.12.12 or ≥ 3.13.4
> > will break up the reflinks of COW data
>
> I thought I was prepared for this, but now I want to try to be more
> certain about what will happen if I start issuing 'defrag -czstd'
> commands. Because version 3.x kernels are mentioned several times at
> specific subversions, the warnings only apply to newer sub-subversions
> of them. I *think* that my 4.15.0 kernel will *not break* reflinks.

It will break reflinks.


> I see that the userspace tools' version tracks along with the kernel
> version. Is it a mistake to use a newer version of the tools than the
> running kernel, i.e. should I drop back to v4.15 of the tools?

No. Ideally use the most recent version you can.


>
> >From the wiki, I understand that while zstd support was added in kernel
> 4.14, user-selection of compression level in zstd was not added until
> kernel 5.1. So I cannot use mount options like "compress=zstd:3" on
> kernel 4.15. BUT, can I yet do "defrag -czstd:3" since I'm running
> v5.4.1 tools? Or, must I (should I) just stick to -czstd and accept the
> default level it would use. What is that for zstd?

Compression level currently is configurable only by mount option.
There are proposals to enhance this for both defragmenting and
property (XATTR). But as level 3 is the zstd default, you will get
zstd:3 just by using zstd.


-- 
Chris Murphy

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-07-27  3:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-07-27  1:59 defrag/compression: will it break reflinks on kernel 4.15.0? Andrew Skretvedt
2020-07-27  3:45 ` Chris Murphy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox