Meltem

Once it is clear, put a limit on the two that regrow: the journal's maximum size, and a scheduled cleanup of the package cache and container images.

A disk that filled once will fill again on the same schedule, and the second time is usually at a worse moment. Ten minutes of configuration now beats repeating this, and an alert at eighty percent means you deal with it rather than the machine dealing with you.

One practical note before changing it in either direction: know how to get back into firmware, and check whether disk encryption is involved.

On some machines, changing Secure Boot state affects the platform module that may be holding a disk encryption key, and the machine then asks for a recovery key you have never seen. That applies to both Windows and Linux setups using it.

So: find the recovery key first, write it down somewhere off the machine, and then change the setting. Doing it the other way round is a memorable evening.

One caution on mixing vendor repositories with a distribution: prefer the vendor's own repository over a package file, and prefer either over pulling in a repository intended for a different distribution.

Repositories from another distribution or another release will resolve, install, and then quietly replace shared libraries that everything else depends on. That is how a working machine becomes one that cannot be updated at all, and it is far harder to unwind than any of the failure modes above.

How to size it, in practice:

• A few gigabytes is enough on a machine with plenty of memory. The old doubling rule was about fitting the whole of memory for hibernation and for running oversized programs, and neither drives the number now.
• If you hibernate, you need swap at least as large as RAM, because that is where the image goes. This is the one case the large numbers still apply to.
• Zero swap is a defensible choice on a server with a well-understood workload and monitoring, and it makes the failure mode abrupt: instead of degrading, the out-of-memory handler kills something. Some people prefer that, deliberately.

The other lever worth knowing is swappiness, which controls how eagerly the kernel swaps. Lowering it does not disable swap; it makes the kernel prefer dropping cache first. On a desktop that usually feels better; on a server it depends on whether cache or resident memory is doing more for you.

The advice comes from different eras because what swap is for has changed, and most of the rules of thumb are answering the old question.

The old purpose was to run programs that did not fit in memory. With plenty of RAM that rarely happens, which is where "you do not need it" comes from.

The modern purpose is different and still applies: swap lets the kernel move rarely-used pages out so that memory can be used for something better. A long-running system accumulates pages that have not been touched in days, startup code, an idle daemon's initialisation. With swap, those go out and the memory becomes cache. Without it, they sit there occupying RAM that would be doing more good as file cache.

So a system with no swap and plenty of memory is not faster. It is slightly worse at using what it has, and it has no margin when something unexpected allocates.