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.

  • Rustmilian@lemmy.worldOPEnglish
    5·
    6 months ago

    If the data is overflowing from Zram into the backing device because it’s 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 realistically should be stored in the RAM that’s not reserved by 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 data first when pushing into the backing device.

    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 of CONFIG_ZRAM_MULTI_COMP to handle cases where the primary algorithm is unable to effectively compress certain data.
    Also, Btrfs uses a built-in pre-compression heuristics algorithm to analyze each file and determine if compression is beneficial.

    TL;DR : Zram itself doesn’t compress data in the backing device. The data written to the backing device is stored uncompressed. 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.

    Tbh, deep down the rabbit hole is an understatement. here’s a more detailed documentation of Zram.