% to get hardcopy of this lecture, you need the following files (plus the
% normal latex and tex base directories):
%     lecture.tex:     latex source file
%     macros.tex:      figure macros
%     psfig.tex:       postscript figure (psfig) macro definition
%     pocs-header.sty: Principles of Computer Systems lecture latex header
%
% run the following programs:
% latex lecture
%   -> Creates lecture.dvi, plus latex intermediate files
% latex lecture
%   -> Run a second time to get cross-references right
% dvi2ps lecture > lecture.ps
%   -> Merges the figures with the text, can also pipe to lpr
%
\documentstyle[12pt,pocs-header]{article}
\Scribes{Clifford Tse}
\Lecturer{Butler Lampson}
\LectureNumber{21}
\LectureDate{November 27, 1991}
\include{macros} % used to include figures in this document
\begin{document}
\MakeScribeTop

\parskip = 5pt

\section{Administrative Information}

Two handouts, lecture note \#17 and solution to PS4.

\section{System Management}

Today's topic is system management.  The area of system management is a big
mess and our knowledge of system management is in disarray, so we will need
a lot of handwaving for this lecture.  

\begin{quotation}
I will wave my hands so fast that you will think it makes sense. -Lampson
\end{quotation}

According to last year's lecture note, system management was loosely
defined by Lampson as ``what you do when you don't know what you are
doing''.  Nevertheless, system management is important
for large systems and most customers require it.  The issues addressed by
system management are normally those not directly related to the function
of the system (such as setting policy) and those not accomplished via an
algorithm.  The definition of system management is not rigid though.
Network routing in some systems has to be done manually and that is a task
of system management; but in many systems, routing is done automatically
and is thus not a system-management task.  In general,
there are some properties of the system that need to be maintained and it
is the task of system management to maintain them.

\section{Naming}

In order to do system management, every component of the system that
exists and must be managed needs to be named.  There are many
different naming schemes.  One of the most common ones is the
hierarchical naming scheme.  Hierarchical names can appear in
different forms but they are essentially the same.  Two typical
examples of hierarchical naming is the Unix file system, e.g.,
/com/dec/crl/lampson, and the SMTP e-mail address, e.g.,
lampson@crl.dec.com.  The basic SPEC required for hierarchical naming
is as follows:

\newpage
\begin{verbatim}
TYPE PN = SEQ[N] 	 % Path Name
     D  = N->UNION[V, D] % Directory

APROC Lookup(d, pn) -> UNION[RECORD[d, pn]], V]

APROC Set(d, n, v)

APROC Enumerate(d) -> SET[N]
\end{verbatim}

Currently a large system will use 10 or 20 different namespaces to name
users, devices, files, etc.

During the lecture, there was a digression on different naming schemes.
The main moral is that in all cases we need the three basic mechanisms of
lookup, set and enumerate.  There was also some discussion about an
object-oriented approach where the thing that you get back from lookup is
an {\em object} to which you can apply operations.  Different operations
would be applied to different object types.  The operations and arguments
can be encoded and given to some transport mechanism that delivers the
encoding to the object. There could be a variety of different transport
mechanisms to get the messages to the object depending on the type of the
object.  So, encapsulated with each object should be the specification of
how to communicate with it.

\section{Tasks of System Management}

The three main tasks of system management are:

\begin{itemize}

\item Control configuration
\item Monitor performance
\item Set Policy

\end{itemize}

We will concentrate on the first two issues and skip policy setting since
there is generally no algorithm to do it and we have little to say
about it.

\subsection{Controlling configuration}

There are three basic issues related to controlling configuration:

\begin{enumerate}

\item {\bf Enumeration}: We need to able to correctly identify the elements
of the system. Typically, each device on a bus has a unique address.  An
example of this is found in the way Ethernet addresses are assigned to
Ethernet controllers.  It would obviously be a problem if two distinct
Ethernet controllers had the same node address.  So in order to make sure
that this doesn't happen, you can send money to a place in California and
they will give you a block of guaranteed-to-be-unique Ethernet node
addresses that you can install in your controllers.

It is possible to engineer a way to find out about all the devices
connected to the machine. This is called {\em autoconfiguring}. There is a
number of ways to find out the information that you need.  If the address
space is sufficiently small, you can just enumerate the entire address
space to find out what is there.  If the address space is very large, like
the Ethernet address space, you could broadcast a request for nodes to
identify themselves and check them off.

\item {\bf Installation and Repair}:  We need some kind of planning capacity.
That is to say, we need to able to estimate/measure the load of the
system and calculate the amount of equipment needed.  Methods for
doing these are rather ad hoc.  We also need to be able to detect
failures.  Although, failure detection may sound trivial, Professor
Lampson gave some examples to show that sometimes failures can be
tricky to detect.  One example is a LAN.  A LAN may still function
when some components failed and those failures may be undetected until
the performance of the LAN is severely degraded.  Another example is
that some operating systems can automatically configure out the bad
memory.  Although, the errors are normally printed out on the console,
they usually go unnoticed.  Professor Lampson also mentioned his
experience with the Xerox Alto's memory system to illustrate the
point.

We also need some mechanism to allow for dependencies among the components
of the system.  One mechanism is version control.  Some systems may not
function correctly if the versions of the components are not compatible.
Ideally, we would like some automatic and mechanical method to figure out
the dependencies.  But, this is not easy.

\item {\bf Load Balancing or Resource Allocation}:  The main issues here
are whether load balancing and resource allocation can be done
automatically (vs.\@ manually) and whether we have a uniform naming
scheme.  A file system is a good example to illustrate this point.  On
the old IBM file systems, allocation was done manually, i.e the user
had to specify which tracks to put a file.  The newer file systems use
physical volumes or logical volumes to reduce the complication, but
some kind of user input is still need.  However, the {\em Plan 9} from
Bell Lab can do allocation and migration automatically to balance the
load on different systems.  Another example is memory systems.  In
most systems, there are different levels of memory: caches, disks,
archives and etc.  Ideally, we would like to have automatic migration
and uniform naming, but sometimes this is not possible, e.g. caches vs.\@
archives.  Other examples of load balancing and resource allocation
include network routing (i.e., which links/nodes should be used) and
replications (i.e., which ones and how many replicas).

In the file system context, replication is usually called {\em backup}.  It
is essentially an attempt to make perfect physical storage from imperfect
primitives.  Terms that are often heard in this context are {\em disk
mirroring} or {\em shadowing}.  This replication at the disk level is
accomplished by having a second disk shadow all transactions of the first
disk - rendering two copies of the same disk.  In this case the backup is
completely automatic and integrated into the system.

If backup is performed while the file system is active, the resulting image
may not reflect any one state of the system.  There are two ways of dealing
with this:
\begin{itemize}
\item Keep a log of changes, i.e. operate the file system like a
transaction system.
\item Turn off the file system and make a disk {\em image}.  This has
the advantage of speed due to sequential track access.
\end{itemize}

\item {\bf Information Replication}:  Sometimes a piece of information may
be broken up into pieces and stored at different places.  The main reasons
for replication are availability and performance.  One form of replication
is that many workstations have local disks where they store some programs
locally.  Another form of replication is binary files vs.\@ source files.
Basically, a binary has the same information as the source file.  File
system backup, mentioned above, is yet another form of information
replication.

The main issue of replication is consistency.  Normally there are some
invariants that we want to maintain among the replicas.  Invariant
maintenance can be done by either updating the invariants on the fly,
or by scanning the system and fixing broken invariants.

\end{enumerate}

\subsection{Monitoring Performance}

In performance monitoring, as shown in Figure~\ref{perffig}, we need first
to establish a model of how the system is supposed to behave.  Then
performance statistics are gathered from the running system and compared to
the model. This information is then fed back into the system so that system
parameters can be adjusted, the configuration changed, or whatever action
necessary to bring system performance into agreement with the model can be
taken.  If we want the system to tune itself automatically, then we need a
way to implement automatic feedback.

\newpage
\begin{figure}[h]
\centerline{\psfig{width=3.5 in,figure=perf.idraw}}
\caption{Monitoring Performance.}
\label{perffig}
\end{figure}

\section{Ackowledgement}

Some of the above information is based on last year's lecture note, as
scribed by Doug DeAngelis and Louise Lemaire. 

\end{document}