Skip to content

Conversation

@charles-dyfis-net
Copy link

For kernels without #107 applied

Copy link
Contributor

@kakra kakra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this should be upstreamed at all. Is there any reason why you'd not want compression of data processed by bees besides working around a kernel bug that should be in the distribution in the first place? The only reasons I can think of would make you force compression off globally anyways.

{ "strip-paths", no_argument, NULL, 'P' },
{ "no-timestamps", no_argument, NULL, 'T' },
{ "workaround-btrfs-send", no_argument, NULL, 'a' },
{ "no-tmpfile-compression", no_argument, NULL, 'N' },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation isn't correct

Comment on lines +518 to +524
if(!bees_tmpfile_compression_disabled) {
BEESTRACE("Getting FS_COMPR_FL on m_fd " << name_fd(m_fd));
int flags = ioctl_iflags_get(m_fd);
flags |= FS_COMPR_FL;
BEESTRACE("Setting FS_COMPR_FL on m_fd " << name_fd(m_fd) << " flags " << to_hex(flags));
ioctl_iflags_set(m_fd, flags);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic is wrong as it won't prevent compression if the parent directory of the tmpfile has the compression attribute set. This would leave you with compression still active even when you said no-tmpfile-compression on the cmdline. That would be quite a surprising effect. Actually, I think it's better to get the updated kernel or force compression off for the whole filesystem if this kernel issue is a concern.

"\n"
"Workarounds:\n"
" -a, --workaround-btrfs-send Workaround for btrfs send\n"
" -N, --no-tmpfile-compression Disable compression for temporary files\n"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the naming could be better: What it actually wants to do is decompressing shared extents. Nobody cares if this is done through tmpfiles or other means. Options should try not exposing too many details of the internal workings so they can still be true after code redesigns.

@Atrate
Copy link

Atrate commented Aug 16, 2025

Considering #107 (comment), I think this should just be closed.

@Zygo
Copy link
Owner

Zygo commented Aug 16, 2025

There is still something to do in this area:

  • Compression does affect extent lengths. Even when no compression occurs, extents are shorter than if compression is not attempted at all.
  • There's no way to set the compression type with this patch. The option could be --tmpfile-compression=MODE to select zstd vs lzo (or anything but zlib), none to force no compression, or btrfs to do nothing with tmpfile attributes and let btrfs decide.
  • New kernels are closer to supporting compression level setting too. The config schema should allow for specifying that when the kernel can set the level through xattrs. (Kernel support is now sufficient to run defrag on the temporary extent with a compression level, so that's another option while we wait for xattr compress-level support).
  • The way that it's currently implemented, if the user does not have compress=zstd in mount options, the tempfile will compress with zlib. It should at least default to zstd, or support a configurable compress type. This is less of a headache than it used to be, because kernels that are too old to support the xattrs or zstd compression are now too old for bees too.

That said, these should be their own issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants