Move swap to a new disk (VM)

Support
1

Hi there,

I’m trying to move my swap that is too small for my Docker server to a dedicated new virtualized disk, so I can grow it faster in the future.

I found that my current swap is partition
in /etc/fstab, there is this entry:

/dev/mapper/almalinux-swap none swap defaults 0 0

Which links to : /dev/dm-1

But I can’t figure out how to link the new disk (or new swap partition, once created) to this /dev/mapper/almalinux-swap symlink

I think modifying it is the right way but be deleting the symlink and linking it to new partition doesn’t work either. I’m still not able to boot once the old partition is removed.

I probably forgot something but I don’t know what… Thanks in advance for your help! :wink:

2

You are not supposed to do that anyway.

The installation did create LVM2 logical volume (“swap”) on volume group (“almalinux”) that was initialized as swap “partition”. The symlink points to that (part of) the first virtual disk. You do not tamper with that link; it is (re)created during boot.

The “right way” is to figure out where the “new virtualized disk” is, and create new/replacement entry to /etc/fstab for it.

What do you get with these:

lsblk
lsblk -f
3

Hi there,

Thanks for the reply. Honestly, it’s beyond my knowledge! :innocent:
Usually I try to find things myself, even if I’m failing, but this one I could not figure it out! That is why snapshots exist!

I get this for lsblk:

NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                  8:0    0   80G  0 disk 
├─sda1               8:1    0  600M  0 part /boot/efi
├─sda2               8:2    0    1G  0 part /boot
└─sda3               8:3    0 78.4G  0 part 
  ├─almalinux-root 253:0    0 76.4G  0 lvm  /
  └─almalinux-swap 253:1    0    2G  0 lvm  [SWAP]
sdb                  8:16   0   16G  0 disk 
sr0                 11:0    1 1024M  0 rom

and this with -f:

NAME               FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                 
├─sda1             vfat        FAT32          7640-9D8A                               591.8M     1% /boot/efi
├─sda2             xfs                        a59ebd6a-768d-46f5-ad98-c7b7efe246a0    595.3M    41% /boot
└─sda3             LVM2_member LVM2 001       gpi4Qm-Kvff-bDJd-GtN7-aAZe-mv8x-IXzacj                
  ├─almalinux-root xfs                        a2562c03-5c4e-46c3-b951-9cd10fbc3334     41.8G    45% /
  └─almalinux-swap swap        1              2352123d-138e-4789-98ca-488f85a4e7e1                  [SWAP]
sdb                                                                                                 
sr0

For now, as I rolled the snapshot back, the new disk is empty and was never used as swap.

PS, fstab looks like this:

/dev/mapper/almalinux-root /                       xfs     defaults        0 0
UUID=a59ebd6a-768d-46f5-ad98-c7b7efe246a0 /boot                   xfs     defaults        0 0
UUID=7640-9D8A          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/almalinux-swap none                    swap    defaults        0 0

What should I do now?

4

PS: maybe I’m doing this all wrong. It’s a docker server with way enough RAM (less than 8Gb is used on 16Gb), but I always get a warning from Zabbix monitoring that the swap is more than 50% full. But I don’t know how Docker use swap even if in that case, it should not.

5

Perhaps that Zabbix is really talking about swap, perhaps about something else.

cat /proc/swaps
free
free -h

The /proc/swaps lists all the swaps that are in use and how much. The free gives nices summary.

Overall, if RAM runs out and system has to swap, then adding swap mainly prolongs suffering.

You have two “disks”: sda and sdb. /dev/sda and /dev/sdb. The /dev/sda has partition table and three partitions in it: /dev/sda1, /dev/sda2, and /dev/sda3

The names “sda” and “sdb” could switch on every boot; they are not persistent.

Note, how the fstab does not list those. It does list UUID=7640-9D8A and UUID=7640-9D8A is the UUID in the filesystem that is within partition /dev/sda1.
Likewise, a59ebd6a-768d-46f5-ad98-c7b7efe246a0 is the UUID of the filesystem in /dev/sda2.
The UUID are persistent, because they are in the data within the filesystems.

The swap has UUID too, 2352123d-138e-4789-98ca-488f85a4e7e1, but that is not used, as the LVM2 unambiguously creates the link “/dev/mapper/almalinux-swap” to it.

If you really want to use the whole second virtual disk as swap, you could initialize the whole block device as swap:

mkswap /dev/sdb

(Make sure that /dev/sdb is the unused disk before you run that.)

After that, the lsblk -f will show UUID for /dev/sdb.
One can then add entry to the fstab:

UUID=...  none  swap  defaults  0 0

where you put the UUID in ...

After that I would:

  1. swapoff -a
  2. remove the /dev/mapper/almalinux-swap none swap defaults 0 0 from fstab
  3. swapon -a
  4. cat /proc/swaps

And the last one should show that only the 16G disk is used as swap.

More interesting is, will the /dev/mapper/almalinux-swap be back in use after reboot.
Logically, it should not, but some bits of config is copied into initramfs that kernel uses early in the boot.
When new kernel is installed (in update), its initramfs gets what you use at the time.

When system no longer uses the “old swap” after boot, its LV can be removed, with lvremove. (See man lvremove)

1 Like
6

Well, this command helped a lot understanding where the problem was… in fact, even if Zabbix stats are showing me a lot of memory free, in real, there is a lot of caching IN memory, which is not considered!

This open a lot more investigation but I think I was over confident that containers were small, there is some taking a lot of RAM and this was not expected.

I’ll still try to move the swap to a separate disk, just for the sake of technical challenges (I love to learn), but final solution resides NOT in swap… you’re right, it’s just more suffering.

Thank you so much for helping me! :blush::ok_hand: