Diskless Architecture

1.0  Introduction

A couple of factors contributed toward the new diskless architecture.  The
major change was the adoption of SVR4 directory hierarchies. Speak with
Jay McCauley to receive "Directory Structure Re-organization in IRIX 5.x".
This paper discusses the entire directory structure change. A second factor
was a need to allow sharing across architectural boundaries and make our
implementation look similar to other vendors. We need to add value where
it will benefit the company the most. Maintaining a different diskless archi-
tecture is not one of them.

1.1  Share Tree

The share tree is that which is shareable. This implies that filesystems are
read-only.  Shareable objects include binaries, news directories, and almost
anything that does not need to be configured on a machine by machine basis.

Everything under the following directories are shareable.  This means that
filenames beginning with the following directories are automatically
installed into the share tree.

o	/usr - 

o	/sbin - Repository for single user shareable objects.  Root binaries
		belong in this directory, not /etc.

o	/lib - Objects placed in /sbin/lib.

o	/stand - Objects placed in /sbin/stand.

Although the share tree contains all the binaries on a running system, it
is not a complete root.  Therefore, performing a "chroot" operation
is not guaranteed to work properly.  The "chroot" part will work; but
scripts can not assume any files other than those under /usr, /sbin,
/lib or /stand are present.  A /dev directory has been
created in the share tree, so chroot will suceed. However, the commands
performed in the operation will determine the success of the pre-op, 
post-op, or exit-op.

To install into the share tree, the share_inst script calls inst
with an option which tells inst that a share tree install is occurring.


1.2  Client Tree

The client tree contains everything which is not in the share tree.  Files
beginning with names other than those listed in the share tree
(see Section 1.1) are placed in each client tree.

There is no way a client tree can be made into a viable root filesystem. 
Therefore, any pre-ops, post-ops, or exit-ops using "chroot" will fail. 
Shell scripts should be re-written to use full pathnames from the miniroot
root.

To install a client tree, the client_inst script calls inst with an
option which tells inst that a client tree install is occurring.  It also
passes the root of the share tree, so inst knows what was installed into
the share tree.


1.3  Swap Tree

This has not changed from the past implementation. A swap file for each
machine is placed in this tree.

1.4  Important facts to remember

Configuration files belong in /etc or /var.  In general, configuration
files have been moved to the /etc directory with large files or directories
being placed in /var.  On a diskless workstation both directories are on the
root partition.  Remember that we aren't concerned about the size of the
root partition as much as maximizing sharing of non-root objects.  On disk-
full machines, however, the space allocated to root is important.  This is
why /var is a symlink to usr/var on diskfull machines.  By placing large 
configuration files or directories in /var, we move them off the root 
partition.

Given the split of files among two different trees, pre-ops, post-ops, and
exit-ops must operate only on those files in that particular tree.  For 
example, coding a post-op for the file /usr/lib/foo which needs to look at
/etc/passwd will not work.  Even if the file /etc/passwd were made available
to the share tree, it would be only one /etc/passwd. Remember, there will be
multiple /etc/passwd files for one /usr/lib/foo file. Running a post-op just
once will not buy much.

Currently, when exit-ops are run there is no way to know if a client
tree or share tree install is happening.