Managing client swap space

Once a client is running, it may need more swap space. Generally, allocating swap space equal to the physical memory on the client is a good start. Power users, or those who open many windows, run many processes in the background, or execute large compute-intensive jobs, may need to have their initial swap allocation increased. You can increase the swap space on a diskless client, without shutting down the client, provided you have sufficient space on the server to hold both the client's old swap file, the server's new swap file, and a temporary swap file equal in size to the old swap file. Here is the procedure:

Create a temporary swap file on the boot server, using mkfile :
```
wahoo# cd /export/swap wahoo# mkfile 64M honeymoon.tmp wahoo# ls -l honeymoon.tmp -rw------T 1 root root 67108864 Jan 9 00:38 honeymoon.tmp wahoo# share -o root=honeymoon /export/swap/honeymoon.tmp
```
Make sure you do not use the -n option to mkfile, since this causes the swap file to be incompletely allocated. If the client tries to find a swap block that should have been pre-allocated by mkfile, but doesn't exist, the client usually panics and reboots.
On the client, mount the temporary swap file:
```
honeymoon# mkdir /tmp/swap.tmp honeymoon# mount wahoo:/export/swap/honeymoon.tmp /tmp/swap.tmp honeymoon# swap -a /tmp/swap.tmp
```
What is interesting about this is that a regular file, and not a directory, is exported, and yet it is mounted on top of a directory mount point. Even more interesting is what happens when you do an ls -l on it:
```
honeymoon# ls -l /tmp/swap.tmp -rw------T 1 root root 67108864 Jan 9 00:38 swap.tmp
```
The /tmp/swap.tmp directory point has become a regular file after the mount.
On the client, add the new swap file to the swap system:
```
honeymoon# swap -a /tmp/swap.tmp
```
Now remove the old swap file from the swap system:
```
honeymoon# swap -d /dev/swap
```
Unmount the old swap file:
```
honeymoon# umount /dev/swap
```
At this point the diskless client is swapping to wahoo:/export/swap/honeymoon.tmp. It is now safe to construct a bigger wahoo:/export/swap/honeymoon.

Remove the old swap file from the server and create a bigger one to replace it:

wahoo# cd /export/swap wahoo# unshare /export/swap/honeymoon wahoo# rm /export/swap/honeymoon wahoo# mkfile 256M honeymoon wahoo# share -o root=honeymoon /export/swap/honeymoon

On the client, remount the expanded swap file, add it to the swap system, remove the temporary swap file from the swap system, unmount the temporary swap file, and remove its mount point:

honeymoon# mount wahoo:/export/swap/honeymoon /dev/swap honeymoon# swap -a /dev/swap honeymoon# swap -d /tmp/swap.tmp honeymoon# umount /tmp/swap.tmp honeymoon# rmdir /tmp/swap.tmp

Remove the temporary swap file from the server:

wahoo# unshare/export/swap/honeymoon wahoo# rm /export/swap/honeymoon

Of course, that is a lot of steps. If you don't mind rebooting the client, it is far simpler to do:

Shutdown client honeymoon wahoo# cd /export/swap wahoo# rm honeymoon wahoo# mkfile 256M honeymoon wahoo# shareall Boot client honeymoon

Note that the last bit in the world permission field of a swap file is T, indicating that "sticky-bit" access is set even though the file has no execute permissions. The mkfile utility sets these permissions by default. Enabling the sticky bit on a non-executable file has two effects:

The virtual memory system does not perform read-ahead of this file's data blocks.
The filesystem code does not write out inode information or indirect blocks each time the file is modified.

Unlike regular files, no read-ahead should be done for swap files. The virtual memory management system brings in exactly those pages it needs to satisfy page fault conditions, and performing read-ahead for swap files only consumes disk bandwidth on the server. Eliminating the write operations needed to maintain inode and indirect block information does not present a problem because the diskless client cannot extend its swap filesystem. Only the file modification time field in the inode will change, so this approach trades off an incorrect modification time (on the swap file) for fewer write operations.