Swap partition in LVM?

Question

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.

Solution

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.

Comments

[Alen Milakovic]

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.

[Levite]

You're right, sry for the mix-up, just edited it! And thx for the response, will do that then!

[Alen Milakovic]

Should I make this a formal answer?

[Levite]

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: blog.zelut.org/2009/03/10/force-contiguous-extents-in-lvm)

[HBruijn]

Never noticed the -C switch, thanks for pointing that out!

[Erk]

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

[HBruijn]

@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

[Erk]

@HBruijn: aha, well, now I have a machine with swap on lvm (on md raid) and it's at least not burning...

[Rui F Ribeiro]

@HBruijn I just did not miss that -C comment by change. Would it be more useful being part of the answer?

[karatedog]

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.