Linux 5.12 Lands Fix For File-System Corruption Caused By Swapfile Issue

[plonoma]

The fix is about properly handling the swapfile read/write offset. Axboe noted in the patch, "We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be..." In other words, clobbering the underlying file-system where the system's swapfile is placed.

They absolutely need to also add tests to detect swapfile issues.
I cannot stress the importance of such swapfile tests enough.

[hsci]

1. "Swap" isn't an acronym like "RAM" is.

2. Having swap available is kind-of necessary for the kernel and the RAM-management as far as I have been informed in the other 5.12-thread on Phoronix.

3. Having swap is necessary for suspend-to-disk, which is a valid use-case.

4. Having memory compressed zram-"swap" is better than not having it. I know, ye olde memory-compressors of the DOS and Windows 9x age have a kind of smell with them but compression algorithms and speeds have improved in the last decades and If you can have RAM or RAM*2 because of highly compressible memory structures - why not? It's practically for free.

5. Having swap can help when unusual spikes of memory consumption appear, e.g. when compiling or when the memory used in the VM cluster suddenly goes up because $USER did something he is allowed to do.

6. Killing processes because of OOM situations is *the* *last* *resort* and should never ever occur in real-life situations. It's like doing a heart transplant without narcotics because it's the last thing left to do. For example before killing processes instruct then to dump their buffers (/proc/sys/vm/drop_caches). Is this done? What's the kernels/systemds OOM strategy? Is there a flowchart?

7. Killing processes because they exceed an arbitary specified memory limit is like deleting database tables because they exceeded one million rows.

You're right. I shouldn't name it emergency buffer. Wording make a lot and mine was generally improper. I suggest everyone reading this:
https://chrisdown.name/2018/01/02/in...e-of-swap.html

• SWAP allows the kernel also to reclaim anonymous pages from the RAM not only file memory from page cache
• CGROUP provides not just a limit for memory consumption with "memory.limit_in_bytes" but also a useful request to keep a process alive when memor exhausting happend "memory.low"
• Depening on your use chase you will prefer either "fail fast. fail hard." with no SWAP or "fail slowly. provide a grace period" with SWAP

You're right that ZRAM is real improvement and suspend-to-disk requires SWAP. You can turn off SWAP usually and even remove kernel support entirely, which is not a problem, and probably a requirement in safety critical- and embedded environments. I need to mention that Systemd new OOMD needs SWAP to gain time to act, when you you use OOMD you need a some SWAP. Probably 512 MB are enough? And there it is getting interesting:

Fedora 33 has removed SWAP Partition/File from the default installation in favor of ZRAM:
https://fedoraproject.org/wiki/Chang...aller_behavior
But they are adding Systemd-OOMD with Fedora 34:
https://fedoraproject.org/wiki/Chang...bleSystemdOomd

Does ZRAM counts as "SWAP" for Systemd-OOMD? They also mention an improvement to remove the necessity of "SWAP" from Systemd-OOMD.

I've enough RAM for my workloads an prefer Suspend-To-RAM (S3), it is okay for me. Probably my attitude to "fail fast. fail hard" is part of this. I'm considering turning on ZRAM, it shouldn't hurt and gave a some grace.

Thanks