the LXD and Snap are fun to watch, Canonical always does things a bit different here and there.
It is perhaps not too surprising but if you ever swap to a non-SSD device you're effective computation rate is reduced by 3 orders of magnitude.
That said, yes, we just got done upgrading all of our workstations to new self-built systems with 64 GB of RAM and I would definitely consider having to go to swap file to be an error.
All of our systems have 5 SSD drives: System, Data, Library, Development, Swap.
They are all 1 TB SSD's with the exception of the 256 GB Swap/Temp drive. The idea is to distribute read/writes and organize things so that no SSD, and, in particular, the system SSD, is abused. Running a large number of FEA thermal simulations or a bunch of FPGA compilation jobs can produce an amazing amount of files.
This approach seems to do a decent job of spreading that out and keeping it off the System drive. That, coupled with local (network) and remote backups has worked well so far.
There's the convenience of being able to re purpose the storage as long as swap isn't being used.
Riiight.
We need a kernel maintainer here.
> The swap file implementation in the kernel expects to be able to write to the file directly, without the assistance of the filesystem.
So apparently it can work with a file that has holes, but then it cannot entirely bypass the filesystem, I guess.
If you mean a fragmented file, it works but it is slightly slower but not by a relevant amount. The kernel just remembers which blocks are in the file and uses these.
As the swap file typically is created during installation it is unlikely to be fragmented anyway.