Managing NFS and NIS, 2nd Edition - Mike Eisler [101]
-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.
Changing a client's name
If you have not changed the default diskless client configuration, it's easiest to shut down the client, remove its root and swap filesystems, and then create a new client, with the new name, using the AdminSuite software. However, if you have made a large number of local changes — modifying configuration files, setting up a name service, and creating mount points — then it may be easier to change the client's name using the existing root and swap filesystems.
Before making any changes, shut down the client system so that you can work on its root filesystem and change NIS maps that affect it. On the NIS master server, you need to make several changes:
Update /etc/bootparams to reflect the new client's name and root and swap filesystem pathnames.
Add the new hostname to the hosts map in place of the old client name. If any mail aliases include the old hostname, or if the host is embedded in a list of local hostnames, update these files as well.
Modify the ethers NIS map if all hosts are listed in it.
Rebuild the bootparams, ethers, and hosts maps.
On the client's boot server, complete the renaming process:
Rename the root and swap filesystems for the client:# cd /export/root
# mv oldname newname
# cd /export/swap
# mv oldname newname
Update the server's list of exported NFS filesystems