Swapfiles aren't dynamic for the same reason, but, you can have multiple swapfiles, and when they are empty, you can discard them. If you really want dynamic swap, you can run swapfiled, which will monitor memory usage and create and mount swapfiles of a given granularity on demand.
If you're going to hibernate, you need that system RAM sized swap space immediately, and what are you going to do if it fails? Right, you need that to be permanently allocated.
If you have a matlab script that needs 1TB of swap, I don't know why you're running it here. Buy a server with a TB of RAM, or rent one. Swapping a terabyte is one of those edge cases where nobody expects the system to be usable for anything else for hours or days.
why would you assume that having a machine with 1TB of free space means that you have any way of spending money ?
A 1 TB swap sounds like it will thrash a disk to the point of failure pretty quickly and perform quite poorly compared to a system with more appropriate amounts of RAM.
Having to replace disks more frequently and have tasks take longer than an appropriately equipped system could potentially be the more expensive in the long run.
> I need about 1TB of swap.
I don't think most people[†] would ever want that much to be dynamically allocated. If something has needed that much memory unexpectedly then it is likely to be something like a massive leak or accidental fork bomb. It could quickly get to the point where a performance drop due to swap thrashing means you can't interact with the system to kill the offending process so your system is effectively locked until either hit the BRB or it runs out of the massive maximum storage allocated to swap. Of course that adds more complexity: how do you decide how much too much is? If it is a user decision and you sometimes want it to be able to balloon that much but still want the OOM killer to deal with accidentally leaky processes at other times, then you are back to manually managing swap allocation before/after processes that are expected to heavily use it.
[†] not that it is wrong to have a use case that warrants it, but if there is a safe workaround for such unusual cases that complicates life just a little, then IMO that is preferable to the risk of adding complexity that will likely go relative untested because it isn't commonly used.
> linux
Of course other OSs have made different decisions on the matter, so maybe there is room for further discussion.
1. Something asks for memory from the kernel.
2. Kernel doesn't have enough free memory, goes to offload something old to swap.
3. Swap file is too small, needs to be extended. This calls the "extend file size" filesystem code.
4. Filesystem code tries to allocate memory for keeping track of filesystem data.
5. Goto 1.
As far as I understand, the "swap file on filesystem" system bypasses the filesystem. The kernel asks the filesystem to give it a bunch of blocks to work with and then ignores the filesystem code entirely. This is why some filesystems can't have swap files -- the FS has to support the right APIs, and has to be prepared for this kind of deal.
In most filesystems, extending an already open file is fairly straightforward - it's usually a matter of writing just a single block.
Since this is an incredibly rare case, there is no strict performance requirement. It could use an approach to filesystems like grub which involves reading and writing just a single block at a time.
And come on, "writing a single block"? No, that's what it looks like on the user side of things. In the kernel it's going to be a good deal more complicated, because how does anything know anything about this block you just added? You need to keep track of it somehow.
Inside the kernel you need to go find some free space to use for this extra block, and to update whatever metadata is needed to make things consistent. It might well turn out that the block you're using to keep track of what blocks belong to this file is just full, so now you have to allocate another block for filesystem metadata. Then there's issues like journalling. And doing all that while providing the guarantee that you won't need to allocate memory is likely tricky.
Windows uses a single file by default (C:\pagefile.sys), while macOS allocates them in chunks (/private/var/vm/swapfile<n>).
Most of the time, I don't need any swap at all, and any swap file/partition is wasted space.
While hibernated, I need ~the amount of system ram as swap.
While running some horrendous matlab script, I need about 1TB of swap.
Yet linux won't dynamically allocate it like other files. I'm forced to constantly resize it manually to save space or be able to do more things.