Linux and macOS definitely name devices differently. Instead of /dev/disk*s# to represent partitions on volumes, Linux typically names them /dev/sd*#, where “*” is a letter representing the device and “#” is a number representing a partition number. (e.g. /dev/sda3 or /dev/sdc1).
For the curious the sd stands for “SCSI Disk”. It was originally reserved for drives connected to SCSI controllers, but was later used for most devices, since the drivers for most devices these days are designed to mimic SCSI devices, for more easier system integration. The exceptions you might see, especially on older PCs, are /dev/HD#*, for parallel-ATA hard drives and /dev/fd# for legacy floppy drives. A SD card (e.g. on an embedded device like a Raspberry Pi) will be /dev/mmcblk#p#, where the first “#” is the card slot number and the second is the partition number.
I would agree with that advice. Back in the old days of mechanical hard drives of smaller capacity, it was common to dedicate an entire hard drive device for swap, so system operation wouldn’t interfere with its head motion (which could cause performance issues).
Later on, when drives got faster and larger, a swap partition would be used, in order to ensure that all of the swap device’s blocks were adjacent, since fragmentation would kill performance (and for some old Unix systems wouldn’t be permitted at all).
Today, swap files are recommended because the OS has no problem dealing with a fragmented swapfile and with SSDs, there is no head motion to cause performance problems. And even if your system has an HDD, the fast seek times (compared to a few decades ago) and caching minimizes the performance problems that used to mandate a swap partition. And with swap files, it is no big deal to add and delete them as your system’s circumstances require (with some Unix-like operating systems, including macOS, dynamically creating and destroying them as needed).
It all depends on your usage patterns. The advice to use 2x RAM size was very important in the days where systems had relatively small RAM sizes (on the order of MB, not GB), because you might end up needing that much when running an app bigger than your system can otherwise handle.
With systems that have much more RAM (64GB in your case), this advice isn’t always the best. If you are overcommitting your memory by 128GB (2x your RAM size), then you are almost certainly running software that is too big for your system, and I would strongly recommend using a computer with more memory (which, of course, would not be a Mac mini) for that application.
Ultimately, you should set the swap size based on how much RAM you expect to need. This could range anywhere from zero up to the point where the performance hit from swapping becomes unacceptable. Some things to keep in mind:
-
When memory actually runs out (RAM is full and swaps are all full), the kernel will start killing processes. This can be a real problem if you need them to be running! So even if you don’t expect to need any swap space, you probably should create some, just in case memory usage temporarily spikes high enough to need it.
-
When viewing memory usage (e.g. with the top command), be sure you understand what you’re seeing. For instance, on one of my Linux PCs, I am seeing this:
Tasks: 196 total, 1 running, 195 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.4 us, 2.3 sy, 0.0 ni, 88.0 id, 0.4 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 5862.1 total, 631.9 free, 696.3 used, 4533.9 buff/cache
MiB Swap: 17166.0 total, 17085.0 free, 81.0 used. 4861.6 avail Mem
This can be a bit confusing. Note the third line. There is 6GB of RAM in the system. Note how it says only 641.9 MB is free when only 693.3 MB is used. This is because of the 4533.9 MB assigned to “buff/cache”. This is RAM used to cache file system data. It’s not free, but it can be released by the OS at any time in order to make room for apps that may need it.
The actual amount of memory that apps can request before swapping is actually 4861.6 MB (the “avail Mem” number to the right of the fourth line). Note that this number is not the sum of free memory and the “buff/cache”. This is because the system always wants to reserve some cache memory, and some memory is reserved for the kernel to use so it won’t crash if it gets to the point where it needs to start killing processes.
I have created a 17 GB swap partition on this computer. Not because I ever expect to need this much, but because I’d rather suffer a big performance hit than see processes killed, should I do something that may require that much.
-
Although the performance hit from swapping to a modern SSD is minuscule compared to an HDD, large amounts of swap activity may create a lot of write-load to the SSD, shortening its lifespan. You may want to avoid the situation even if there is no significant performance hit.
- Alternatively, if you want to connect an external SSD (USB or TB) to be used as a swap device, that might be a good idea. This way you can swap all you want and if it dies, it won’t take down the rest of your system. It won’t be as fast as swapping to the internal SSD, but may be good enough.
-
If you choose to enable hibernation (sleep-to-disk), then you will need a swap file at least as large as your RAM size. This is because Linux hibernation works by swpping-out everything and then powering off. Then on reboot, it swaps everything (or most of everything) back in.
But if you don’t think you’ll ever use hibernation, then you don’t have to care about that.
-
I personally believe that if RAM is plentiful (as it appears to be for you - with 64GB), then you shouldn’t expect to swap at all. So I would suggest creating a small-ish swap file (e.g. 4 or 8GB), just to pick up the slack should it be needed), or (if you plan on using hibernation) one equal to the RAM size.
I honestly think that if you need more than 64GB for your expected usage, then you should start researching buying a PC with enough RAM and not try to use a Mac mini for its tasks.