35

I was wondering if putting the swap partition into a logical volume group has any drawbacks (e.g. performance), or would it be "just the same" as having it as a separate primary/logical partition?

I like the fact that it could be easily resized if necessary, but am not sure about possible drawbacks.

Case of application: CentOS 7 Webserver.

Mat
  • 51,578
  • 10
  • 158
  • 140
Levite
  • 483
  • 1
  • 4
  • 7
  • 1
    I'm not sure what you mean by "putting the swap partition into a LVM group". I understand what you mean by having swap on a logical volume. I've done that on past machines and my current personal workstation. I have never noticed any problems, nor can I think of a reason why problems should occur. On my current machine, swap is used, though not very much. – Faheem Mitha Jul 15 '14 at 08:51
  • You're right, sry for the mix-up, just edited it! And thx for the response, will do that then! – Levite Jul 15 '14 at 08:56
  • Should I make this a formal answer? – Faheem Mitha Jul 15 '14 at 08:57

1 Answers1

50

Of course the primary goal is not to have the need to use swap in the first place...

The main thing is to create the swap LVM volume when the system is still quite fresh, the same as when you create a swap file, as swap space performs best when it is contiguous, or enforce that with lvcreate -C option. You don't want to actual disk blocks that make up the logical volume to be fragmented all over your disks. Resizing the swap volume (frequently) should be avoided for that reason as well.

As one of the lead developers of the Linux kernel, Andrew Morton says:

The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code.

That bypasses all the LVM code as well, swap goes straight to disk. And thus there is from a performance perspective no difference in swap partition, a swap file or a LVM volume.

HBruijn
  • 7,233
  • 23
  • 32
  • 15
    Great answer, thx for the detailed explanation! "`That bypasses all the LVM code as well, swap goes straight to disk.`", exactly what I was looking for! Concering the resizing issue: would it make sense, for that reason, to recreate the swap volume after installation with the -C option to ensure it to be/stay contiguous? Like `lvcreate -C y -L 10G VolGroup -n swap` (reference: http://blog.zelut.org/2009/03/10/force-contiguous-extents-in-lvm/) – Levite Jul 15 '14 at 09:14
  • 5
    Never noticed the `-C` switch, thanks for pointing that out! – HBruijn Jul 15 '14 at 09:51
  • "uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code" -- though that answer is for journaling file systems (ext3/reiserfs) I'm wondering if it really bypasses md raid... that would make tons of advice for swap on raid out there pretty use/clueless... – Erk Aug 26 '18 at 21:46
  • @Erk with regards to raid, notice that file systems are still an abstraction layer above the IO device, I.e. when using raid for swap probably all the usual considerations still apply, regardless of hard- or software raid – HBruijn Aug 26 '18 at 21:57
  • @HBruijn: aha, well, now I have a machine with swap on lvm (on md raid) and it's at least not burning... – Erk Aug 27 '18 at 17:47
  • @HBruijn I just did not miss that -C comment by change. Would it be more useful being part of the answer? – Rui F Ribeiro Sep 26 '18 at 16:12
  • The original article is about ext3 where linux can perform I/O directly to disk. I don't think Linux will collect all abstracted information on every type of PV that LVM accepts. A PV can be a software RAID array which can contain multiple disks or it can be an iSCSI block device. Or a 100 MB LVM LV can be 10 different 10MB sized PV made from partiitons and the kernel should have to know which underlying device is involved and how to handle it. Which would mean the swapping code in the kernel took over responsibilities and state information which is handled elsewhere, which I highly doubt. – karatedog Aug 28 '19 at 16:02