Originally posted by AndyChow
View Post
Announcement
Collapse
No announcement yet.
Fedora Workstation 34 Looking To Employ Btrfs Zstd Transparent Compression By Default
Collapse
X
-
Originally posted by intelfx View PostThe only actual problem with compress-force is that it forces btrfs to break files into 128 KiB (or so) extents, because this is the maximum size of a compressed extent. If several extents in a row end up rejected by the encoder and stored uncompressed, they will not be "fused". This leads to metadata bloat and very high fragmentation levels.
Comment
-
Originally posted by AndyChow View Post
My understanding is that when just compress is used, btrfs checks the first block is compressible, and if not, skips compressing the whole file. If you have things like virtual disks in raw, this can trigger false-negatives, i.e. the file could be compressed efficiently, but won't be. Forcing compress means any file or archive which is non-compressible, will be compressed, which can often actually result in a larger file than the original. For example any lzma or 7z file you have will end up being compressed in zstd, which will often result in a larger file than the original. Compressing a compressed file doesn't result in magic.
I'm curious your choice of compression level. Default is 3, why go with 1? I keep default at 3 for home, 9 for archive arrays. ZSTD goes from 1 to 15 (if you set at 0, it's 3).
IMHO, this situation is what Zstd-fast:1000 & LZ4 are for...fire & forget transparent compression.
What I find funny is the kernel's Zstd is something like version 1.3 or 1.3.3 and doesn't have access to Zstd-fast. It's worth mentioning because ZFS uses Zstd 1.4.5 (it brings its own Zstd). Basically, the same data will compress faster and better on ZFS with the exact same Zstd levels in use. Just food for thought.
Comment
-
Originally posted by curfew View PostBullshit. The extents are anyway going to be 128 KiB and the same metadata bloat and fragmentation affects all compression-enabled partitions including compressible data, not just the data that is incompressible.
Originally posted by curfew View PostSo if you don't view this fragmentation as an issue with compressed data, it hardly is an issue with non-compressed data.
Originally posted by curfew View Post(My feel is that the incompressible data would have to present a majority of the data on the partition in order to be considered problematic.)
Comment
-
Originally posted by intelfx View PostZstd has its own compressibility check within the encoder itself, and another compressibility check on the encoder-filesystem transition. If an extent turns out incompressible, it will be rejected by the encoder and stored uncompressed on the btrfs level (i. e. not "compressed" with ratio 1.0, but as an actual uncompressed extent). Thus, using compress-force=zstd will not, under any circumstances, result in files larger than the original. It will potentially waste cycles trying to compress incompressible data, but that's about it.
So now you have highlighted two considerable issues WRT forced (attempted) compression: 1) high levels of avoidable fragmentation 2) potentially high levels of wasted CPU time.
The maximum disk space savings seem to be around 40-45 % for optimal compressible data. So that's the level we can achieve with compress-force, but we also have to accept the aforementioned drawbacks. How about the default compressibility heuristics? What is the amount of "unachieved gains" when using simpler heuristics that -- based on your conclucion -- will not incur the two major drawbacks. Just my gut feeling makes me think the little bit gained extra compression isn't worth it with all the downsides that come with it.
Comment
-
Originally posted by cynic View Post
yes, especially on some workloads and on HDD, btrfs is slow, but the extra features, if you need them, make this bearable.
are your bad experiences on HDD or SDD?
- Likes 1
Comment
-
I would expect something like lz4 just to make sure that compression will never bottleneck SSD performance.
Very surprised about choosing zstd. even "1" level is very slow for modern ssds (and even worse for SSDs in raid): https://github.com/lz4/lz4
Comment
-
Originally posted by C8292 View PostI would expect something like lz4 just to make sure that compression will never bottleneck SSD performance.
Very surprised about choosing zstd. even "1" level is very slow for modern ssds (and even worse for SSDs in raid): https://github.com/lz4/lz4
- Likes 2
Comment
-
Originally posted by curfew View PostBullshit. The extents are anyway going to be 128 KiB and the same metadata bloat and fragmentation affects all compression-enabled partitions including compressible data, not just the data that is incompressible. So if you don't view this fragmentation as an issue with compressed data, it hardly is an issue with non-compressed data. (My feel is that the incompressible data would have to present a majority of the data on the partition in order to be considered problematic.)
With normal compress mount option, then uncompressed extents can be larger than 128KiB, while with compress-force always limits them to 128KiB or less. If you were to store a nice big 10GiB video file it would create at least 81920 extents with the compress-force option even if the file wasn't compressed.
- Likes 1
Comment
-
Originally posted by hubick View PostGreetings from Fedora 33 running ext4 on bare partitions (no LVM). Maybe someday I'll change. Sometimes you just wanna K.I.S.S., you know? Just me?
├─nvme0n1p1 259:6 0 1G 0 part /boot/efi
├─nvme0n1p2 259:7 0 1G 0 part /boot
├─nvme0n1p3 259:8 0 900G 0 part
│ └─luks-********-****-****-****-***********
│ 253:0 0 900G 0 crypt /
└─nvme0n1p4 259:9 0 29,5G 0 part
└─luks-********-****-****-****-***********
253:1 0 29,5G 0 crypt [SWAP]
Comment
Comment