So, I’m sure some of you know. If configured, you can use a backing device for Zram for scenarios where Zram can’t compress the data, e.g. when it’s full. For this you can use pretty much any supported partition format, including btrfs, what I realized is that you can used btrfs disk compression on top of that. Question is, is this a good idea? 😅 I imagine you’d want to use LZO-RLE or Zstd.
I’m really deep down the Zram rabbit hole, and I’ve been thinking about all kinds of scenarios.
Maybe a few of you are interested in joining me down this rabbit hole and can share some of your own experiments.
If it’s not compressible, it’s not compressible. Algorithm isn’t going to make much difference. Already compressed media, for example, can’t really be compressed. In fact, if you try, you might just find it actually ends up bigger than the original.
TL;DR :
Zram itself doesn’t compress data in the backing device. The data written to the backing device is stored unmodified by Zram. Zram’s function is to compress data within its allocated RAM space. Once that space is full, any incoming data, compressed or uncompressed, overflows to the backing device unmodified by Zram.
If the data is overflowing from Zram into the backing device because the Zram block is full, that doesn’t necessarily mean that data is uncompressible. It simply means that there’s no place to put it even if it was compressible. The truly incompressible data ideally should be stored in the RAM that’s not allocated to the Zram block device, unless that RAM space is also already taken, then that data would go to the backing device. The scenario I’m thinking of is a lot more specific. Ofc, Zram would prioritize truly incompressable & idle data first when pushing into the backing device, keyword there is
"idle", which supports the idea that the data isn’t necessarily uncompressible.Already compressed media, for example, can’t really be compressed. In fact, if you try, you might just find it actually ends up bigger than the original.
There’s no case where this would happen, the data being pushed to the backing device is always unmodified by Zram, regardless if it’s compressible or not. Also, already compressed media would not necessarily be seen as incompressible by Zram. Zram can still compress already compressed data to some extent, depending on the type of compression used and the compressibility of the original data. For example, if the original data was compressed using a simple algorithm like LZMA, Zram might be able to achieve better compression using a more advanced algorithm like LZ4.
However, the benefit of compressing already compressed data with Zram is usually minimal as you’ve already said.
This is the primary purpose ofCONFIG_ZRAM_MULTI_COMPto handle cases where the primary algorithm is unable to efficiently compress certain data.
Also, Btrfs uses a built-in pre-compression heuristics algorithm to analyze each file and determine if compression is beneficial. Comparatively, Zram has no such mechanism so it attempts compression regardless.Tbh, deep down the rabbit hole is an understatement. here’s a more detailed documentation of Zram.
Edits : Wording improvement’s and added supporting sources.
