From: Irene A. Shilikhina (irene@alpha.iae.nsk.su)
Date: Wed Jun 11 2003 - 01:05:33 EDT
What informative replies I've got... and an exhaustive background from
DEC/COMPAQ/HP experts. So, not to miss any valuable information, I'll
quote some answers (for future readers of the archives), but a short
summary is:
It's important: I don't use LSM to mirror root (see the answer by Martin
Moore). So, I changed to "lazy" (called also "commitment" or "overcommit")
swapping mode (i.e. moved aside the symlink /sbin/swapdefault pointing to
the former "primary" swap space), edited fstab removing swap1 and retaining
the other, rebooted the system, and voila - "swapon -s" shows what I
expected. It seems, in "lazy" mode, the notion "primary swap" doesn't exist
and everything relies on fstab. Some respodents have no swap space at all
(I guess, if the physical memory is sufficient, which is not in my case).
Just a comment: I only need such a manoeuvre for restoring the damaged
boot disk since there is an evidence it's the primary swap partition that
is a culprit. At the same time, this system has not enough physical memory,
and dump|restore surely needs swapping, so it's for the sake of avoiding
failure during this procedure. Fortunately, swap2 was larger than swap1.
Many thanks (in the order of arrival) go to:
Nikola Milutinovic
James Sainsbury
Meiklejohn David
Paul Gallop
Thomas.Blinn
Steve Thompson
Martin Moore
Alan Rollow (glad to meet you on the list again :).
Quotes from some answers and the original post are under the signature.
Irene
*************************************************************************
* *
* Irene A. Shilikhina e-mail: irene@alpha.iae.nsk.su *
* System administrator, *
* Institute of Automation & Electrometry, *
* Siberian Branch of Russian Academy of Sciences, *
* Novosibirsk, Russia *
* http://www.iae.nsk.su/~irene *
*************************************************************************
* *
* The road to hell is paved with good intentions. *
* *
*************************************************************************
>From Meiklejohn David:
I use dedicated swap disks, i.e. no swap on the system disk, for one of the
servers here. It runs Tru64 5.1A, so I can't tell you that 4.0D will work
for certain, but I don't see why it wouldn't.
Tru64 does not actually need a swap partition to boot - it will come up in
overcommitment mode if one is not defined, so I'm quite sure that you will
be ok.
--------------------------------------------------------------------------
>From Paul Gallop
I run some v4.0d/e alphas and I have set them up
without any swap space at all.
--------------------------------------------------------------------------
>From Tom Blinn:
In V4.0x you need to look at the /sbin/swapdefault symlink and make it
point to the "primary" swap partition if you want "eager" swap mode.
If you want "lazy" swap mode, remove (or move aside) the symlink so it
no longer exists, and the swap choices will be made entirely from your
/etc/fstab entries.
If your /sbin/swapdefault points to a disk partition, that partition
will be used for swap even if it's not listed in /etc/fstab.
In V5.x things change significantly, but you say you are using V4.0D.
There is NO requirement (in any release) that you have a "primary"
swap, or that it has to be on the boot disk. So you won't find any
statement to that effect. However, the DEFAULT location set up by
the installation procedure is always on the boot disk, in the "b"
partition. It's good practice to have your swap space on a disk that
isn't used for a lot else if you do a lot of swapping. If you really
have enough physical memory, you can swap to any disk and the need is
to have more swap space available that the combined memory needs of
your entire workload, if you use "eager" swap. If you use "lazy" swap
you need enough swap for all the pages that ever actually need to be
swapped out at the same time.
Yes, it's all rather confusing.
Tom
---------------------------------------------------------------------------
>From Steve Thompson:
No, the primary swap partition does not have to be on the boot device. I
have many systems for which this is true. Usual disk availability
considerations apply.
---------------------------------------------------------------------------
>From Martin Moore:
In most cases, swap does not have to be on the same disk as root. The
exception (in V4 and earlier) is if you are using LSM to mirror root. In
V5, even this restriction is gone.
---------------------------------------------------------------------------
>From Alan Rollow:
There was a point in the history of ULTRIX (Digital's UNIX
operating system before DEC OSF/1, Digital UNIX and Tru64
UNIX), that the system *dump* device had to be on the same
disk as the boot disk. I think this was because the console
disk driver was used to write the dump. I think.
Early versions of DEC OSF/1, may have had a similar limitation
though probably for a different reason.
All that said, look at the other side of it. Given sufficient
real memory and low enough virtual memory needs, you can get
by without any page/swap space. Lacking it, you simply run
in "lazy" or overcommit mode.
Without a dump space, you won't be able to save a crash dump,
but in a sufficiently stable system that shouldn't be an issue.
I think modern versions will chain crash dumps across all
necessary page/swap spaces if the primary isn't large enough.
Finally, when you do run in overcommit mode, what is the
"primary" page/swap space. The first one added? The one
that happens to end up on the same disk as the root? I
think of overcommit mode as not having a primary at all,
but many (or one) secondary spaces.
Given the options available in configuring page/swap space,
I think it is reasonable to take an open minded view of
what must be done.
At the same time, I suspect most testing is done in the same
old conventional configurations. Without regular and extensive
testing of the more creative variants, there's no telling what
subtle problems may lurk. And while such problems may not be
in the operating system, 3rd parties may make assuptions about
typical configurations. As a short-term workaround for a
problem, you're probably safe.
----------------------------------------------------------------------------
On Tue, 10 Jun 2003, Irene A. Shilikhina wrote:
>
> >From the swapon manual:
>
> Usually, the swap device number is the same as the boot device
> number, and the primary swap partition is partition b.
>
> Well, "usually" doesn't mean "always". But in a far corner of my memory
> there sits something which tells me that the root and primary swap partitions
> MUST be on the same device. Unfortunately, I can't find the exact answer
> in the archives.
>
> Some explanation:
>
> Having a problem with the system disk (confirmed with scu: Nonrecoverable
> medium error, plus, for a short time, lots of error messages from uerf
> concerning this target), I'm getting prepared to change the disk and going
> to do that in a day or two. But meanwhile, I thought...
>
> The matter is that a couple of times there was an error "Failed to write
> initial header to primary swap". So, it's quite possible that the damaged
> part of the disk falls on the primary swap space. The system has two swap
> spaces. And I thought, why not to edit fstab switching swap1 to the other
> disk, exclude swap2 and look at the situation further. At the same time,
> I'm afraid it's not possible. Yes or no? Version 4.0D, if this matters.
>
> Thanks,
> Irene
>
> *************************************************************************
> * *
> * Irene A. Shilikhina e-mail: irene@alpha.iae.nsk.su *
> * System administrator, *
> * Institute of Automation & Electrometry, *
> * Siberian Branch of Russian Academy of Sciences, *
> * Novosibirsk, Russia *
> * http://www.iae.nsk.su/~irene *
> *************************************************************************
> * *
> * The road to hell is paved with good intentions. *
> * *
> *************************************************************************
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:21 EDT