Hibernate with LVM Swap

Lamont R. Peterson lamont at gurulabs.com
Tue Jun 13 19:36:57 UTC 2006


On Tuesday 13 June 2006 12:47pm, Peter Jones wrote:
> On Mon, 2006-06-12 at 19:51 -0600, Lamont R. Peterson wrote:
> > So, Peter, are you saying that using up 3 partitions is so bad compared
> > to 2 that we should be concerned about it?
>
> Yes, absolutely.  That being said, the economy of partitions themselves
> isn't the only advantage.  What if you wanted to make your swap device
> *smaller*, and give the freed space up to some already extant
> filesystem?  If it's not on LVM, you really can't do that.
>
> Really, it's this simple: if you're going to have LVM for anything, you
> want to use it wherever it's possible on your persistently attached
> storage.  For us, right now, that means everything except /boot .
>
> > Sorry, this is a non-starter argument to me.
>
> Consider dual booting and other such scenarios.

OK.  I do.  On both my home workstation and my current notebook, I "dual" boot 
with Windows XP Professional, OpenSUSE 10.1 and FC4/5 (haven't updated the 
home system to FC5 yet :( ).  I have never had a problem with running out of 
partitions.  Of course, none of my servers dual-boot, so they are using even 
fewer partitions than these two boxes.

> > I'm saying that LVM has several very worthwhile benefits and that non of
> > them matter when it comes to swap and that since LVM doesn't benefit
> > swap, it doesn't make sense to put swap on LVM.
>
> That's just not right.  It's worth doing it if for no other reason than
> conserving partitions.

Conserving them for what?

> > The only exception I see is the example of needing 30GB of RAM to do some
> > big, one-time operation.  In that case, sure, create an extra swap LV and
> > use it, removing it when you're done.
>
> In that scenario, paging out to swap at all is almost certainly
> something you want never to happen.  But these days, that's true most of
> the time anyway.
>
> Moreover, there isn't a compelling reason *not* to do it.  This
> hypothetical performance-while-swapping argument you've got just isn't
> reality.  You're not CPU bound when you're swapping.  You're I/O
> limited, and most of the limit isn't time on the host bus, it's disk
> seeks.  I really doubt if LVM will make any significant difference --
> measurable difference, that is, much less noticeable by a human -- at
> all.

Of course.  Yes, swapping is not memory or CPU bound, it is I/O bound, as you 
state.  However, I wasn't talking about LVM code overhead, I was talking 
about drive seek overhead in heavy swapping situations.

If you are doing heavy swapping with a swap partition, the on disk storage is 
contiguous and, therefore, you will have less distance to travel when 
seeking.

On LVM, the PEs could be spread around the disk more widely (i.e. 
non-contiguous), so the heads will have farther to go.  If you're *really* 
lucky, your heavy swapping pattern will let you alternate (or rotate, if that 
word fits better) around each of the disks with PEs backing your swap LVs 
LEs. But, the likelyhood of that working out is very small.  This is why I 
said that to get better swap performance, just have separate swap partitions 
and let the swap code deal with spreading things out, use a high-speed, 
dedicated disk or use software or hardware RAID0.  I would pick separate swap 
partitions over RAID0.

You are right, though; most users will probably not notice, most of the time.  
It won't be human noticeable until it hits the fan, until you are stuck with 
heavy swapping, at which point, it's (probably) too late to do anything about 
it.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060613/3c6dad1a/attachment.sig>


More information about the fedora-devel-list mailing list