All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Skretvedt <andrew.skretvedt@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: defrag/compression: will it break reflinks on kernel 4.15.0?
Date: Sun, 26 Jul 2020 20:59:11 -0500	[thread overview]
Message-ID: <rflcdf$bc5$3@ciao.gmane.io> (raw)

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)


             reply	other threads:[~2020-07-27  2:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27  1:59 Andrew Skretvedt [this message]
2020-07-27  3:45 ` defrag/compression: will it break reflinks on kernel 4.15.0? Chris Murphy

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='rflcdf$bc5$3@ciao.gmane.io' \
    --to=andrew.skretvedt@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.