Find swap on linux

Содержание

How does Linux know where its swap partition is?
4 Answers 4
What happens in systemd operating systems
the native mechanism
automatically generated unit files
installer programs and the systemd way
Further reading

How does Linux know where its swap partition is?

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.

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

@zakinster: What about when your 1TB drive is always full? Storage needs have increased with storage provisions.

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»

@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.

4 Answers 4

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.

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.

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?

… 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.