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

[zexelon]

Okay, this one is bothering me.... if writing to a file (albeit a special file sure) can destroy the underlying file system... is there not some sort of severe security risk lurking here?

How could the underlying file system code allow a miss behaving file write to destroy the rest of the file system? Are there not safety mechanisms in the file system abstraction code that ensure the writes are only happening in the area they are allowed to?

Did this bug only affect file systems built on EXT4 (all the test cases I have seen so far) or were other file systems affected (i.e. xfs, btrfs, etc.)?

This one raises a ton of red flags in my mind about a potential flaw elsewhere in the file system handling code tangential to the swap file handling changes.

Can anyone with some time see if they can replicate this by hammering say a 8gb VM file stored on a ext4 fs?

[DRanged]

How do you hibernate your system without swap?

I don't hibernate I switch off, saves battery/electricity. Plus it is way more secure.

[ResponseWriter]

If I understand this correctly, it's caused by having a swap file stored on another device so zram is safe? Since I have 32GB and can avoid using swap entirely I can worry less about being on rc1 right now (no, it didn't fix my amdgpu issues).

[60Hz]

SWAP? In 2021

SWAP is an emergency buffer and of no use when RAM is affordable. But I hear still of people who follow this ancient MS-DOS rule "SWAP shall be twice as big as RAM". The result? They add 8 GB to already installed 8 GB RAM, now total 16 GB RAM. And then they add 32 GB of SWAP. But that doesn't make any sense and they should actually remove the SWAP entirely.

On the other hand we still don't use the full capabilities of CGROUPS to control actual resource usage. When a web browser consumes more memory than allowed (let us say 8 GB for Firefox in 2021) the kernel shouldn't provide more - which most likely kill the application nowadays. Maybe the new daemons and changes in the kernel improve that situation but starting swapping till the system becomes unresponsive isn't a solution.

SWAP itself isn't bad. But I didn't added SWAP for many years to my systems. And I don't have huge amounts of RAM.

No one can be this obnoxiously clueless and so self-assured about it without being deliberate bait. 4/10.

[cynic]

I don't hibernate I switch off, saves battery/electricity. Plus it is way more secure.

No, you don't saves any battery or electricity more than hibernation.
Hibernation is actually powering off the machine.

Also, setting up my working environment often requires a lot of effort starting from a clean boot: I need to run several container, the IDE, a DB interface, an handful of console to monitor the logs, the browser and the mail client.

Hibernation saves me a lot of time every single day.

[Zan Lynx]

Also, I have 32 Gb of RAM, is a swap partition or a swapfile still needed when I barely go over 9 Gb being used?

Yes. I have 64 GiB of RAM here and current have 2.1 GiB in swap. The "top" program has an option to display a SWAP column and sort by it.

Most of my swap is from the Windows virtual machine which has 24 GiB allocated but has been idling for a while. Then there's almost a gibibyte used by various parts of Android Studio. Then Skype, Teams, Slack and Steam. All of those use a web browser backend, probably Electron, allocate 300 MiB and then don't use most of it.

[pal666]

SWAP? In 2021

SWAP is an emergency buffer and of no use when RAM is affordable.

if ram is affordable to you, you are using too small datasets

now total 16 GB RAM

i had 32gb on home computer in 2017. and i have swap because "no swap" means wasted ram.

they should actually remove the SWAP entirely.

you should avoid giving bullshit advice

When a web browser consumes more memory than allowed (let us say 8 GB for Firefox in 2021) the kernel shouldn't provide more - which most likely kill the application nowadays.

why users should lose their most important application?

starting swapping till the system becomes unresponsive isn't a solution.

swap to fast ssd then. btw, "swapping till the system becomes unresponsive" can happen with zero swap, because mmapped files(like binaries of your running apps) will be dropped and reread as needed

SWAP itself isn't bad. But I didn't added SWAP for many years to my systems. And I don't have huge amounts of RAM.

now try to run game which doesn't fit in memory(without killing it that is)

[torsionbar28]

With intel having taken away the S3 sleep state in recent generations, I suspect swap will become more and more relevant. Anyone who's tried the new S0ix sleep state in Tiger Lake knows how complete and utter crap it is, keeping almost the entire system powered on during "sleep" and running your battery out in a matter of hours. Compare that with the old S3 sleep state that could go for *days* without depleting a laptop's battery. This awful S0ix is going to drive users towards Hibernate, rather than sleep.

Hibernate is super fast on modern NVMe storage, and consumes zero battery. Of course in order to hibernate, you need a swap space that is at least equal to physical RAM + zRAM. So a laptop with 16 GB of real RAM, plus 4 GB of zRAM, will require a 20 GB swap partition in order to hibernate. Unfortunately distros are now doing 0 swap by default, relying exclusively on zRAM, so hibernate is broken out of the box, and requires the user to manually re-configure their machine.

[pal666]

Also, I have 32 Gb of RAM, is a swap partition or a swapfile still needed when I barely go over 9 Gb being used?

rest will be used as cache. depending on your file and memory access patterns it could be useful to spill some memory to swap and increase cache size. also swap is required for hibernate, your fast suspend doesn't depend on ssd speed because it's suspend to ram

[pmorph]

It's been at least 10 years since I had any kind of swap in use.
Running out of ram with any of my uses cases would mean something went horribly, horribly wrong. Having swap might help in identifying the scenario that caused the issue, but not really worth it just for that theoretical benefit (imo).