Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjustable max compressed extent size #786

Open
ErrorNoInternet opened this issue May 2, 2024 · 3 comments
Open

Adjustable max compressed extent size #786

ErrorNoInternet opened this issue May 2, 2024 · 3 comments
Labels
enhancement kernel something in kernel has to be done too

Comments

@ErrorNoInternet
Copy link

I wonder if it would be possible to allow the user to tweak the maximum size of a compressed extent (which is currently hardcoded to 128 KiB) on a per-file/subvolume basis? This would be useful to:

  • increase compression ratios
  • decrease fragmentation on large, write-once-read-many files
  • possibly make LZ4 worthy again
  • decrease write amplification on flash storage with lower compressed extent sizes

On ZFS this is possible with recordsize (per-dataset), on bcachefs with --encoded_extent_max (per filesystem; set during mkfs time, per-subvolume/file support is planned), and on F2FS with the compress_log_size mount option (or per-file with f2fs_io set_coption <algo> <4KiB * 2^this> <file>).

@kdave kdave added kernel something in kernel has to be done too enhancement labels May 2, 2024
@kdave
Copy link
Owner

kdave commented May 2, 2024

Yeah, it would be good. I used work on that in my early years, there's a project idea https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Project_ideas.html#Compression_enhancements and I maybe still have some of the code. This needs format change due to encoding of the flexible length.

With more CPU power we have nowadays the compression chunks could be larger which saves metadata and naturally enables better compression ratios, namely for ZSTD.

How it could be configured is an separate issue, but in general possible to do per-file/per-subvolume/per-fs.

@adam900710
Copy link
Collaborator

I believe the main blockage is just how to persistently save such config value.

We also have qgroup auto-reap waiting for such guide line, and to me they are really the same requirement, no on-disk format change at all, just a runtime behavior change.

So no matter if it's some PERSISTENT key change or superblock flags change, just let us conclude on a proper way to save such value.

@Forza-tng
Copy link
Contributor

Would an xattr be suitable since we already use the xattr btrfs.compression? Maybe we could extend it and use btrfs.compression_extsize?

Today we can do

> setfattr -n btrfs.compression -v zstd file
> getfattr -n btrfs.compression file
# file: file
btrfs.compression="zstd"

It could be extended to

> setfattr -n btrfs.compression -v zstd file
> setfattr -n btrfs.compression_extsize -v 512 file
> getfattr -n btrfs.compression file
# file: file
btrfs.compression="zstd"

> getfattr -n btrfs.compression_extsize file
# file: file
btrfs.compression_extsize="512"

Of course we could use btrfs property set as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement kernel something in kernel has to be done too
Projects
None yet
Development

No branches or pull requests

4 participants