Page partitions and paging files

28 views
Skip to first unread message

Neil Marko

unread,
Oct 31, 1997, 3:00:00 AM10/31/97
to

Way back when, when you needed to increase paging space, you needed to do
this nonsense with update_disk_label. This was fine on an empty disk, but
was a major pain on a quite full one (especially with a 1600bpi tape)!

Then along comes the magic "paging file." When they first came out I was
told that they are not as fast as paging partions since they go through the
file system, but that they are a good inteim solution if you have a disk
that has a lot of stuff on it, or if the disk is used in production and
can't be taken down. But recently, I saw a new Continuum shipped with
serveral disks and the master disk had a paging partion but the other disks
got paging files! When the question of paging partions was put to our
support people we got the somewhat blank stare that is usually associated
with trying to ask a dog a question.

Now on a new machine, does not it make sense to plan and put paging
partions on other disks in addition to the master disk. Would anyone want
to reply with the procedure for doing so, instead of me trying to get the
info from the CAC. (First question they ask is "Why not use a paging file
instead?") Alternatively, is the overhead of the "paging file" so small as
to make it not worthwhile to bother with paging partions?

--
Neil Marko


Paul Green

unread,
Nov 3, 1997, 3:00:00 AM11/3/97
to

Neil Marko <nma...@EatTIHSSpammers.isyssoft.com> wrote in article
<01bce62a$25c343a0$88de94cd@iss_office_cx>...

> Way back when, when you needed to increase paging space, you needed to do
> this nonsense with update_disk_label. This was fine on an empty disk,
but
> was a major pain on a quite full one (especially with a 1600bpi tape)!
>
> Then along comes the magic "paging file." When they first came out I was
> told that they are not as fast as paging partions since they go through
the
> file system, but that they are a good inteim solution if you have a disk
> that has a lot of stuff on it, or if the disk is used in production and
> can't be taken down. But recently, I saw a new Continuum shipped with
> serveral disks and the master disk had a paging partion but the other
disks
> got paging files [...]
>
> [...] is the overhead of the "paging file" so small as

> to make it not worthwhile to bother with paging partions?

Paging files and paging partitions are indistinguishable in efficiency. And
paging files are much easier to change (grow or shrink) than paging
partitions. That's why we've changed the process.

PG

Dan Danz

unread,
Nov 4, 1997, 3:00:00 AM11/4/97
to Neil Marko

Neil Marko wrote:
>
> Way back when, when you needed to increase paging space, you needed to do
> this nonsense with update_disk_label. This was fine on an empty disk, but
> was a major pain on a quite full one (especially with a 1600bpi tape)!
>
> Then along comes the magic "paging file." When they first came out I was
> told that they are not as fast as paging partions since they go through the
> file system, but that they are a good inteim solution if you have a disk
> that has a lot of stuff on it, or if the disk is used in production and
> can't be taken down. But recently, I saw a new Continuum shipped with
> serveral disks and the master disk had a paging partion but the other disks
> got paging files! When the question of paging partions was put to our
> support people we got the somewhat blank stare that is usually associated
> with trying to ask a dog a question.
>
> Now on a new machine, does not it make sense to plan and put paging
> partions on other disks in addition to the master disk. Would anyone want
> to reply with the procedure for doing so, instead of me trying to get the
> info from the CAC. (First question they ask is "Why not use a paging file
> instead?") Alternatively, is the overhead of the "paging file" so small as

> to make it not worthwhile to bother with paging partions?
>
> --
> Neil Marko


Let's see if I can put to rest a few of the myths and dispel a few
misunderstandings inherent in any discussion, like this, about paging
files.

HISTORICAL PERSPECTIVE:

H1) A VOS disk contains multiple, fixed-size partitions. Some of them,
like the paging partition, have their blocks allocated at the time the
disk is initialized, and can only be (painfully) resized when the disk
is being salvaged. The disk label records the starting block number
and number of blocks in each partition.

H2) VOS builds a list of paging partitions at boot time. Each
partition is recorded in a PP_data node structure that includes a bit
map of which blocks in the partition were free or in use. The nodes
are linked together in a circular list, and a roving finger pointer is
advanced around the list as the operating system "withdraws" or
"deposits" blocks of paging partition pool.

H3) A system administrator who wanted to re-apportion the space among
the partitions could not do so dynamically. A time-consuming
reboot/salvage operation was required, while VOS moved blocks around on
the disk so that the blocks in the paging partition could be contiguous.

H4) It was hard to get VOS to recognize a new paging partition on a
disk added after the system had booted.

PAGING FILES

To overcome the inflexibility of paging partitions, and allow a site to
dynamically re-allocate some of the space, VOS engineers created paging
files. Some characteristics of them are:

P1) They start simply as files whose space is allocated in the file
partition of the disks.

P2) The file becomses special when it is made available for paging
operations by use of the add_paging_file command.

P3) Each extent of the file is treated (as in H2 above) as a separate
paging area; that is, VOS creates a PP_data node for EACH EXTENT in the
file.

Thus, the differences between paging files and paging partitions are:

D1) You can only have one paging partition on a disk, but you can have
many paging files.

D2) Each paging partition has contiguous blocks in one large extent,
while paging files have contiguous blocks in at least one extent, but
can have many non-contiguous extents (not always a good thing, see
below).

SIMILARITIES:

S1) The withdraw/mechanism is exactly the same.

S2) The scheme has nothing to do with the efficiency of disk I/O to the
blocks on disk; the I/O mechanism remains unchanged. However, note
considerations C1 and C2 below:

CONSIDERATIONS:

C1) I/O operations to multiple paging blocks might have different
access times depending on where the blocks are allocated. Just by the
nature of the implementation, it is possible to have more head movement
of the disk. By the same token, having a huge paging partition on a
disk can have the same seek time considerations.

C2) Simultaneous multiple I/O operations are possible if paging files
are added to a data disk that heretofore didn't have a paging
partition. This can, in fact, improve paging I/O performance. Spread
your paging files across the disks and overlap I/O operations among
them. Avoid the (master_disk) with its dedicated paging partition and
frequent paging of read-only pages of the kernel code from the boot
partition, and also avoid high-use application disks.

C3) Extent sizes for paging files MUST BE AS LARGE AS POSSIBLE. Do
NOT create paging files when the largest extent size you can get is 128
blocks, even though the add_paging_file command will allow it.
Consider a 32,000-block paging file where the maximum extent size is 128
blocks; this creates 250 extents, each of which is considered a mini
paging partition by the kernel. Space is allocated on an as-needed
basis for all processes running on the module by advancing the finger
around the circular list of (at least) 251 nodes in the allocation list.
VOS first locates the next node in the list that has free space and then
finds the block number by consulting the bit map in the node. Since the
space in each mini-partition is small, they tend to become full, forcing
the node to be skipped over during withdraw operations. This
inefficiency pales in comparision, however, to what happens when a
program terminates and each block of the paging space is returned to the
pool. Before the "bit" that represents the block can be set to show it
free, VOS must first locate the PP_data node in kernel memory from which
the block was allocated. This is a linear search through the linked
list with the routine holding a lock all the time, and it occurs FOR
EVERY BLOCK that is "deposited". It can, and does, cause mini-hangs of
systems whose system administrators ignored the caution to make the
extent sizes of paging partitions as large as possible.

C4) Allocate paging files early in the life of a disk pack when
fragmentation of the file partition has not yet occurred. The CAC has
some tools that can be used to find the largest extent that can be
used. Sometimes, files can be deleted and the freed space can be
coalesced to create larger free extents that can then be allocated to a
new paging file.

Want to know how good/bad things are at your site? Look at each paging
file and total the number of extents for each. Add to this total the
number of true paging partitions. If the total is 10 or under, you're
in great shape. If the total is between 11 and 50, think about doing
something. If the total is more than 50, you're wasting a lot of
system time and you really should do something about it.

I hope this helps you understand what's going on under the hood.

If you have further questions, please contact your Customer Assistance
Center.


--
L. W. "Dan" Danz (WA5SKM) NeXT Mail: dd...@az.stratus.com
Senior Technical Consultant VOS Mail: Dan_...@vos.stratus.com
Stratus Computer, Inc. Direct Phone: +1-602-852-3107
Customer Assistance Center Fax: +1-602-852-3099
4455 E. Camelback #A-115, Phoenix AZ 85018: +1-800-294-1344 x3107

Reply all
Reply to author
Forward
0 new messages