[OpenIndiana-discuss] Swap during install

[Reginald Beardsley]

--- On Mon, 9/24/12, Jan Owoc <jsowoc at gmail.com> wrote:

> From: Jan Owoc <jsowoc at gmail.com>
> Subject: Re: [OpenIndiana-discuss] Swap during install
[snip] 

> I agree that the "correct" answer, if one exists, depends on
> system
> use. I would imagine a text-only install used as a file
> server (or
> other simple tasks) is unable to use more than 1-2GB of
> swap, so I
> would set swap = 2x RAM, to a maximum of 2GB :-).
> 
> Would it be best if the installer give an option of setting
> the swap
> size (I'd be annoyed if my file server installer decided to
> eat up
> 200GB of disk space for swap), mentioning some general
> guidelines? Or
> is the size of swap easily changed after installing (this is
> the ideal
> case, as I might not know the amount of swap I need until
> I've
> installed and run some benchmarks)?
> 
> Jan
> 
> _____

It certainly should ask as only the person doing the install knows how it will be used. However, unless ZFS knows to allocate contiguous blocks for swap it may not matter.

In my case, I am a research geoscientist, so long running (days not hours) jobs are standard fare.  Being able to stop a long running job, do some other work, and then resume it is very handy. Admittedly w/ 12 GB of DRAM I'm not sure I'd run a job that big, but I do tend to do odd things.

When I ran VMS 4.x on a MicroVAX, I setup the batch queues so that they had very small working set quotas but extents equal to all of memory.  As a result we could run the machine at 100% CPU utilization for weeks at a time yet interactive users perceived it as an idle machine.  That's difficult to do w/ the Unix fork-exec model, though one could implement a queuing system that would suspend jobs if the non-queuing system load average crossed a threshold and accomplish the same result.  If a job takes 300 hours of CPU time, you *really* don't care if it takes slightly longer wall time, but you *do* care if it's hard to edit files to setup another job because the editor got paged out.

There's a question about whether one should use separate partitions for swap.  As noted, the paging system used to interleave the I/O between two disks if you had a pair of matched partitions.  I've been meaning to test that, but don't have a suitable system at the moment.  The system running OI only supports a single disk (nettop) and the system w/ multiple disks is running Sol 10.  And the latter has far too much important work on it to play around.

However, if ZFS is really smart about paging space in a pool, the current practice of putting swap in rpool may be the best choice. Growfs should easily  adjust the size.  Given the number of lies being told about disk geometry at various stages, it's hard to feel confident one knows what's actually going on.  It becomes particularly opaque when one considers the differences among SCSI, SAS & SATA disks.

Some questions I have in case someone knows the answers:

Does ZFS allocate contiguous space for swap?

If swap in grown, does ZFS keep the space contiguous?

How is swap handled if rpool is a mirrored pair?

Would striping swap improve performance?

Have Fun!
Reg