13

I've read that you need to put the swap partition on HDD rather than SSD.

My questions are the following:

  • When and how is the "checking" done by the distribution (or something else) to find its Swap partition?
  • Does it happen during boot?
  • It just checks all available disks and searches for a partition with 'swap' flag?
  • What happens if there are several partitions like that?
  • Also, how many swap partitions do I need to have if I run, for example, two different distributions on the same disk, let's say Fedora and Ubuntu?
Kusalananda
  • 333,661
DisplayMyName
  • 317
  • 2
  • 11
  • 17
    Note that a swap on SSD would actually be a really great swap (macOS is doing so for ages). It is however going to do additional read/write to the SSD which might reduce its lifespan. – Nonyme Feb 20 '18 at 21:55
  • 20
    Where did you read that swap should be on an HDD not SSD? Also, how old was the article or comment? Modern SSDs are much better at wear leveling and do not fail after repeated writes the way they did when SSDs were new. Also, if you have a computer that only has SSDs, then you really don't have much choice, other than not use swap at all – JDS Feb 20 '18 at 22:35
  • 1
    @JDS: Actually, modern flash is much worse. The first generation flash was Single-Level Cell (SLC) which would last 100.000+ writes. Modern flash is TLC, which dies after about 5000 writes. This is with the benefit of hindsight, though. We always knew that flash would die. It just turns out that it lasts longer than we thought, which is why we can afford TLC despite its relatively inferior reliability. – MSalters Feb 21 '18 at 10:09
  • 2
    @zakinster: What about when your 1TB drive is always full? Storage needs have increased with storage provisions. – Lightness Races in Orbit Feb 21 '18 at 11:15
  • 3
    In other words, "yes I agree, contrary to my previous statement the actual size of the disk is irrelevant - it's how much of it you're using" – Lightness Races in Orbit Feb 21 '18 at 14:31
  • "I've read that you need to put the swap partition on HDD rather than SSD." That would be utterly foolish. If you're using swap in only small or negligible amounts, it won't matter. If you're using swap in significant amounts, you'd much rather have the performance of your SSD than your HDD. That might have been sensible advice back when SSDs were tiny and space on them was precious, but it's nonsense today. (The wear issue is only an issue if you are absurdly cheap and don't care about performance.) – David Schwartz Feb 21 '18 at 18:02
  • 6
    @DavidSchwartz And, if you're "using swap in significant amounts", while an SSD will produce considerably less perceived system performance loss than an HDD, the better option will still be to either add more RAM to the system, or reduce the virtual memory footprint of your workload in some way to stop the significant swap usage. Also note there's a difference between a long running system that has filled up swap with almost-never used data vs. a system that is actively swapping and scanning... – twalberg Feb 21 '18 at 19:46
  • 2
    Question comments are not really the place for a long multiple person discussion of different types of storage media, tangential to the actual questions asked. I suggest that all of the people wanting to discuss this find or create a proper question like https://superuser.com/questions/1256074/ on the subject and contribute to it. – JdeBP Feb 21 '18 at 22:20
  • 1
    @DavidSchwartz It's still an issue for durability though. I'd only do it if I had an extra throwaway SSD to use for swap (such as a lower capacity one from before an upgrade, that I'm no longer using) – user253751 Feb 21 '18 at 23:09
  • @immibis It's really not. That's largely a myth. – David Schwartz Feb 22 '18 at 00:09

4 Answers4

24

Statically configured swap space (the type that pretty much every distribution uses) is configured in /etc/fstab just like filesystems are.

A typical entry looks something like:

UUID=21618415-7989-46aa-8e49-881efa488132    none    swap     sw      0  0

You may also see either discard or nofail specified in the flags field (the fourth field). Every such line corresponds to one swap area (it doesn't have to be a partition, you can have swap files, or even entire swap disks).

In some really specific cases you might instead have dynamically configured swap space, although this is rather rare because it can cause problematic behavior relating to memory management. In this case, the configuration is handled entirely by a userspace component that creates and enables swap files as needed at run time.

As far as how many you need, that's a complicated question to answer, but the number of different Linux distributions you plan to run has zero impact on this unless you want to be able to run one distribution while you have another in hibernation (and you probably don't want to do this, as it's a really easy way to screw up your system).

When you go to run the installer for almost any major distribution (including Fedora, OpenSUSE, Linux Mint, Debian, and Ubuntu), it will detect any existing swap partitions on the system, and add those to the configuration for the distribution you're installing (except possibly if you select manual partitioning), and in most cases this will result in the system being configured in a sensible manner.

Even aside from that, I would personally suggest avoiding having multiple swap partitions unless you're talking about a server system with lots of disks, and even then you really need to know what you're doing to get set up so that it performs well.

Austin Hemmelgarn
  • 11,867
  • If you have 2 Linux distro, you may have one swap partition for system... so you may try to hibernate and resume... (better to use different users BTW and you should need different /tmp partitions/directory too). Probably in that case it is better to have virtual machines... – Hastur Feb 21 '18 at 06:29
  • So what is suggested for one to do if they have a dedicated partition for swap on the same SSD that the Linux OS is installed on, however, doesn't seem to actually have swap or for it to be in use. If I run systemctl --all | grep swap I get back two results. dev-disk-by\x2duuid-1c692cc4\x2df942\x2d4478\x2dad0f\x2d266b7484273a.swap and swap.target both of which are ACTIVE=inactive and SUB=dead. How do I get my system to make use of the swap area? – Rockin4Life33 May 26 '19 at 13:59
21

let's say Fedora and Ubuntu?

… both of which are nowadays systemd operating systems.

What happens in systemd operating systems

the native mechanism

Systemd employs various kinds of units. .mount unit files instruct it to mount volumes. .swap unit files instruct it to tell the kernel about swap partitions. (.service unit files instruct it how to run services. And so on.) These are the native systemd mechanisms. To enact them, systemd itself forks off child processes that make the relevant system calls.

If you use the systemctl command (with --all) on such a systemd operating system, it will tell you about the loaded .swap units. For example:

dev-disk-by\x2dpartuuid-40549710\x2d05.swap loaded    active   active  /dev/disk/by-partuuid/40549710-05
dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap loaded active active    /dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
dev-sda5.swap loaded    active   active  /dev/sda5

It will also tell you about the .mount units.

A system administrator can actually write such .swap unit files by hand, just as xe can write .service, .socket, and other unit files by hand. systemd itself just looks for unit files in the filesystem. They are its native mechanism.

One can even get systemd to show you what is in these unit files and where in the filesystem they can be found:

$ systemctl cat dev-disk-by\\x2duuid-1bb589e8\\x2d929f\\x2d4041\\x2d81f4\\x2dff2b339b4e2a.swap 
# /run/systemd/generator/dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)

[Swap]
What=/dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
Options=sw
$

automatically generated unit files

One can write them by hand. Usually however such .mount and .swap unit files are automatically generated by programs known as generators. Two such generators are systemd-fstab-generator and systemd-gpt-auto-generator. They both run early in the bootstrap process and in response to a systemctl daemon-reload command, and (as you can see above) they generate a whole load of unit files into an undocumented subdirectory in /run/systemd/. systemd itself just uses those generated unit files.

The former generator reads /etc/fstab, recognizing several systemd extensions to that file format. As I pointed out in an answer comment, traditionally swap partitions have the mount type of sw and that is how one will find that other operating systems recognise swap records in this table. But Linux softwares have taken the alternative tack of recognizing the VFS type instead, looking for swap as the VFS type. systemd-fstab-generator is no exception here, and that is how it interprets /etc/fstab when converting it into the native mechanisms.

The latter generator processes the EFI partition table that is on the same disc that holds the EFI System Partition, looking for EFI partition table entries that have various well-known partition type GUIDs. One of those GUIDs is the conventional GUID assigned to Linux swap partitions; and if systemd-gpt-auto-generator finds a partition with that GUID (that satisfies the criteria given in the systemd doco) it will make a .swap unit for it; no /etc/fstab involved at all.

Of course, this process has lots of side-effects. For example, because /etc/fstab has no primary key to the table, records can have duplicate "spec" and "file" (i.e. "what" and "where") fields. In the native systemd mechanism, though, the "file" (i.e. "where") field is a unique key for .mount units, embedded into the unit names. No two .mount units can share it. For .swap units the "spec" (i.e. "what") field is the unique key for units. No two .swap units can share that. So not all records in /etc/fstab are necessarily convertible to the native mechanisms and will work, especially if people do things like list the same mount point for two different purposes or list the same swap partition in two different ways.

Similarly, because it has translated /etc/fstab into the native mechanism and systemd's native mechanism has other ways of activating units, the behaviour is subtly different to that of non-systemd operating systems. A .mount unit will, by default, be automatically activated by systemd-udevd, even after bootstrap, in response to the appearance of the mounted storage device. Or it can be listed as a Wants= or Requires= of some .service or .socket unit, meaning that it will be (re-)activated when they are. There is even RequiresMountsFor=.

installer programs and the systemd way

Traditionally, operating system installer programs, and the systemd administrator afterwards reconfiguring the system, have written sw entries to /etc/fstab. And that is how the native .mount and .swap units end up being auto-generated. The install/configuration utility "knows" where the swap file was put, because in its user interface the system administrator made some sort of choice, and writes an /etc/fstab to match. Sometimes that choice is I need you to make me a swap partition as part of installation.; sometimes it is Just use the swap partition that you have found already on the disc. (installers looking at the partition types, too).

But the systemd people have this idea of operating systems that auto configure themselves from a largely empty /etc tree, so-called stateless systems, and that is what mechanisms like the generator that reads the EFI partition table are all about. In the systemd people's plan, there is no /etc/fstab, and indeed is no persistent configuration data under /etc at all, and all of this stuff is deduced from the contents of the partition table on disc, at every bootstrap and at every systemctl daemon-reload. They are nowadays promoting operating system installer programs than do not write an /etc/fstab.

In the traditional scheme, of course you can indeed have each operating system have its own private swap partition, and not have them touch one another's swap partitions. And indeed if you are using hibernate to disc via a swap partition and expecting to be able to multi-boot to another operating system whilst hibernated (which is a very bad idea because it is very easy to cause filesystem corruption this way) that will be necessary.

In the systemd scheme, even if the operating system is not yet as the systemd people envisage it and "stateless", the aforementioned generators run; and thus all swap partitions (on the ESP/root disc) with the requisite partition type are automatically employed by all systemd operating systems. Since they will be sharing all automatically discovered swap partitions, one really does not need to create one swap partition per installed operating system.

Further reading

JdeBP
  • 68,745
  • Very nice -- thank you for the explanation! – Andy Dalton Feb 21 '18 at 14:47
  • There is a part of me that wants to actually down vote you just for talking about systemd. But of course that's unfair (and also systemd or no doesn't mean you're wrong) and I don't typically down vote things anyway as it never seemed to me to be the appropriate way to be constructive. It is however a nice write up so despite seeing references to Lennart I have up voted this answer. If nothing else you put effort into it and it should be praised. I have read briefly about the stateless rubbish and that's something that rather ... I'm not even sure what it does so I'll just leave it at that. – Pryftan Feb 21 '18 at 19:58
13

Historically, the swap partition is specified in /etc/fstab with an entry of type swap. On boot, the startup processes will read that file and push that configuration into the kernel.

An example of the entry in /etc/fstab is:

/dev/sdb    none    swap     sw      0  0

I'm not familiar with how systemd manages swap, but I do believe that the end result is the same: a userspace process is aware of what space is allocated for swap, and the userspace process informs the kernel.

Andy Dalton
  • 13,993
  • The questioner asked about Linux, and this is not wrong for Linux; but it is peculiar to Linux. Other operating systems, such as FreeBSD for example, recognize swap records in /etc/fstab from their sw mount type rather than from their swap VFS type. – JdeBP Feb 20 '18 at 20:29
  • 1
    The answer doesn't address all parts of the question. – Sergiy Kolodyazhnyy Feb 20 '18 at 20:32
  • I should also point out that this answer, too, is out of date in the world of systemd operating systems. It fails to take into account systemd-gpt-auto-generator. – JdeBP Feb 20 '18 at 20:42
  • 2
    What do you mean systemd doesn't use fstab? Of course it does! – psusi Feb 20 '18 at 21:20
  • 1
    @psusi: systemd understands, but does not require fstab. – MSalters Feb 21 '18 at 10:12
  • @MSalters Technically and literally speaking, just because it doesn't require it doesn't mean it doesn't use it. So actually the statement that it does use it is actually correct whether or not it needs it. – Pryftan Feb 21 '18 at 19:59
  • @JdeBP Out of date..or incomplete? For all my systems I use /etc/fstab and unfortunately all my Linux systems are systemd enabled. – Pryftan Feb 21 '18 at 20:02
4

All the other answers mention how to point to a swap filesystem at boot.

However, several points to add to the other answers:

  • the swap space can also be a file;
  • a swap space partition is marked usually as type 0x82;
  • you can mount a swap space at any point in run-time;
  • for marking/initialising a partition/file, for it to be recognised and used/mounted later on as swap space, you need to use the command mkswap;
  • for activating/using a swap partition/file by hand you use the command swapon;
  • likewise for swapping it off, you go with swapoff.
Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232