Hacker News Reader

Comment by man8alexd | Hacker News Reader

You are right, it is not a rule of thumb, and you can't determine optimal swap size right away. But you don't need "extensive runtime analysis". Start with a small swap - a few hundred megabytes (assuming the system has GBs of RAM). Check its utilization periodically. If it is full, add a few hundred megabytes more. That's all.

View on HN

It's not like it's easy to shuffle partitions around. Swap files are a pain, so you need to reserve space at the end of the table. By the time you need to increase swap the previous partition is going to be full.

Better overcommit right away and live with the feeling you're wasting space.

Exactly opposite. Don't use swap partitions, and use swap files, even multiple if necessary. Never allocate too much swap space. It is better to get OOM earlier then to wait for unresponsive system.

Swap partition is set and forget. Can be detected by label automatically, never fails.

Swap file means fallocating, setting extended attributes (like `nocow`), finding file offset and writing it to kernel params, and other gotchas, like btrfs not allowing snapshotting a subvolume with an active swap file.

Technically it's preferable, won't argue with that.

Hast thou discovered our lord and savior LVM?

> Swap files are a pain

Easier than partitions:

    mkswap --size 2G --file swap.img
    swapon swap.img

Yeah, until you need to hibernate to one. I understand that calculating file offsets is not rocket science, but still, all the dance required is not exactly uninvolved and feels a bit fragile.

Reply on news.ycombinator.com