Fedora Workstation 33 Aiming To Have SWAP-On-ZRAM By Default

[skeevy420]

Hibernation by default aims for 40% compression of RAM(2/5th the size). You can reduce that target to 100%(5/5) if you don't care for compression and it'll just write the contents to disk. On a SATA SSD, if it has to write 48GB yeah that would be slow, around 1 min 30? But afaik only actual allocated memory is written to disk for hibernation?

I still use HDDs. More storage for less money. A reboot cycle is faster than multiple GBs to and from a spinner.

[xinorom]

I still use HDDs. More storage for less money.

Sure, for large media storage, backups, etc... but using a HDD for your main system partitions in 2020 is extremely cheapskate. If you're a heavy computer user, I'd even say that not using an NVMe drive is bordering on cheapskate...

[skeevy420]

Sure, for large media storage, backups, etc... but using a HDD for your main system partitions in 2020 is extremely cheapskate. If you're a heavy computer user, I'd even say that not using an NVMe drive is bordering on cheapskate...

You're not wrong with that assessment. I've been waiting on them to be priced below $100 per TB and they're just now getting to that point. Upgrading to those also means adding a PCIe card with more sata ports and moving my current drives there since I don't think my system will support PCIe drives as boot volumes and I'm out of sata ports.

I'm content with mirrors and raid0 on HDDs for the time being.

[S.Pam]

So when will we get compressed swap on disk? Seems far more useful. Especially if an application actually needs a lot of ram, as zswap takes valuable ram.

[skeevy420]

So when will we get compressed swap on disk? Seems far more useful. Especially if an application actually needs a lot of ram, as zswap takes valuable ram.

Use ZFS.

zfs create -V 8G \
           -o compression=lz4 \
           -o logbias=throughput \
           -o sync=always \
           -o primarycache=metadata \
           -o secondarycache=none \
           -o com.sun:auto-snapshot=false \
           poolname/swap

Maybe BTRFS and a swap file (starshipeleven might know) or F2FS with a swap file once F2FS compression support lands.

[S.Pam]

Unfortunately compressed swap files are not supported. I guess the swap file actually just acts as a place holder for the physical address the swap writes to.

The problem with using an underlaying filsystem is that even if you can compress a 4KiB memory page, you still have to write out a block, and most FS's uses 4KiB blocks. It wouldn't save any I/O. What is needed is a virtual swap address so that several blocks can be combined. This is done in-ram with zbud/zsmalloc for zswap.

[skeevy420]

Unfortunately compressed swap files are not supported. I guess the swap file actually just acts as a place holder for the physical address the swap writes to.

The problem with using an underlaying filsystem is that even if you can compress a 4KiB memory page, you still have to write out a block, and most FS's uses 4KiB blocks. It wouldn't save any I/O. What is needed is a virtual swap address so that several blocks can be combined. This is done in-ram with zbud/zsmalloc for zswap.

zstd+z3fold

[S.Pam]

zstd+z3fold

What do you mean? Z3fold is also the same. Does not compress on-disk.

[starshipeleven]

Unfortunately compressed swap files are not supported. I guess the swap file actually just acts as a place holder for the physical address the swap writes to.

Yes it is like that for every filesystem that supports swap files.
The swap file is allocated as contiguous and it is a "special file". Any filesystem logic ignores that area from that moment onwards, all writing and reading to it is done by kernel directly, by physical address.

I'm personally against using a filesystem to compress swap as it adds a layer of stuff that does not make sense for swap, and will slow down the job. Any compression should happen at the kernel level (which is the one actually reading and writing to disk) while the swap file remains this special file thing.

The fact that ZFS can do shenanigans like that is one of the things I don't like about it, it tries to do stuff that isn't its job, if the kernel sucks and can't compress swap, if there is no decent tool to make smb or NFS shares and whatnot, your friggin filesystem (and tools) should NOT take over and do that.

Among other things it is a violation of Unix principles, but of course that's a thing that is only read very wrong for the sake of bashing systemd, but I digress.

That said, I have the strong suspicion that swap and "lack of RAM" issues in general have been mostly ignored in the last decade because you could easily "fix" them by adding more RAM on PC/Servers, or keep using ancient 2.6 kernels (for embedded devices where RAM footprint is significant).

I also personally think compressed swap isn't particularly relevant in this day and age where 512GB SSDs are getting cheap. I would like a lot a solution for the DoS issue that swapping and low RAM causes (i.e. lockup), but that's another story.

[S.Pam]

That said, I have the strong suspicion that swap and "lack of RAM" issues in general have been mostly ignored in the last decade because you could easily "fix" them by adding more RAM on PC/Servers, or keep using ancient 2.6 kernels (for embedded devices where RAM footprint is significant).

I also personally think compressed swap isn't particularly relevant in this day and age where 512GB SSDs are getting cheap. I would like a lot a solution for the DoS issue that swapping and low RAM causes (i.e. lockup), but that's another story.

First of all, not always easy to add more RAM. That aside, your point about SSDs is not relevant either. compression outperforms read/write rates of even very fast SSDs. Compression would not only reduce the user waiting for swap, but also reduce bytes written on the SSD which increases its life span.