% 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{Doug DeAngelis and Louise Lemaire}
\Lecturer{Butler Lampson}
\LectureNumber{21}
\LectureDate{November 28, 1990}
\include{macros} % used to include figures in this document
\begin{document}
\MakeScribeTop

\parskip = 5pt

\begin{quote}
Science without religion is lame; religion without science is blind.
{\em Albert Einstein}
\end{quote}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Administrative Information}

The only handout today was the lecture notes for Lecture \#19.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Management Pragmatics}

Today's lecture dealt with management in large systems and can be
translated into a job description for system managers.  Management
was loosely defined by Dr. Lampson as ``what you do when you don't
know what you are doing''.  The issues addressed are typically those
not accomplished via an algorithm.  In general, there is some
invariant that needs to be maintained, and it is actually maintained
by the {\em manager}.  A variety of pragmatic issues related to large
systems were discussed and are enumerated below:

\begin{itemize}
\item Physical Resources or {\em configuration} issues
\item Resource Limits or {\em allocation} issues
\item Accounting
\item Replication
\item Management
\end{itemize}

They are classified as pragmatic in as much as they differ
from the other types of issues that we have been talking about in
class: issues of abstract correctness.  Most of these issues are
discussed within the context of that universal example, the file
system.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Physical Resources}

Some examples of physical resources in the file system are disk
drives, controllers, and the "volume" abstraction which is mapped onto
physical disk space and used by the file system to store its data.
The arrangement of these resources is termed the {\em configuration},
an example of which is shown in Figure~\ref{physfig}.  This
configuration consists of a number of disks and a number of drives,
some of which are dual-ported.  The dotted line represents the
addition of a port to one of the drives, and must be treated as a
change in the configuration.

\begin{figure}
\centerline{\psfig{width=2.5 in,figure=phys.idraw}}
\caption{The changing of a configuration.}
\label{physfig}
\end{figure}

There are three basic issues relating to configuration of the physical
resources:

\begin{enumerate}

\item {\bf Enumeration} is the correct identification of the elements
of the system. Typically, each device on a bus has a unique address.
But we need to be able to deal with the situation of two
devices on a bus having the same address.  This is done in one of two ways:

\begin{itemize}
\item Design an algorithm that diagnoses the problem when it
happens. This is hard.
\item Make sure it never happens. This is probably easier.
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.
\end{itemize}

It is possible to engineer a way to find out about 
all the devices connected to the machine. This is called {\em autoconfiguring}. There
are a few 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's 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 Learning the connectivity} involves similar techniques to
find out how the components that have been enumerated are actually
arranged in the system.
\item {\bf Allocation} is the first step that requires user input of
some form.  Here, we allow the user to tell us, for example, how much
of a disk should be allocated for swap space, how much for temporary
files, etc.
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Resource Limits}

In the file system example, the essential issue pertaining to
resource limits is disk space. In previous lectures, when we
have talked about the file system, we have pretty much ignored the
possibility of there being limits on the amount of space we have.
In real life, however, you have to pay money for resources like disks,
and so they are limited. Whenever you have limited resources,
you need to keep track of their use.

The problem of resource limits and managing a resource can
be broken down into the following three items:

\begin{enumerate}
\item {\bf Allocation} problems can be handled with data structures to keep
track of free and/or used space, or both.  This is not a hard problem.

\item {\bf Resource Exhaustion}, e.g. when the disk is full, can cause
undefined behavior if not handled properly.  From the point of view of
the client, this is where there is a possible impact on the
abstraction: you just can't keep creating files and writing to them
with reckless abandon - it may not be possible if the disk is full.

The way to deal with this is two-fold. First, the file system should
raise an exception to report that there are insufficient resources to
complete a request. Second, programs should check for this exception and
take appropriate action.  The appropriate action may be to notify the
humans and abort. In you have a program that is expected to run a long time
without human intervention, aborting is probably not an appropriate action.

The important point here is that the interface should be properly
documented so that a user can know what to expect.

\item {\bf Quotas or Scheduling} can be used as a means of defining how
a limited resource is shared.  The term quota is generally used when
referring to sharing fixed resources, such as a disk. The term
scheduling is used when referring to sharing a resource such that if
you wait, more of the resource will become available, e.g. CPU time.

To implement disk quotas, you can use a table indexed by user that
contains information about how much disk space a user is allowed to
consume.  Note that this complicates things significantly because
\begin{itemize}
\item it introduces the notion of users
\item the table must be robust (in stable storage)
\item operations on the disk become more complicated because they must
check and write quota information for write and delete operations.
\end{itemize}

An important point derived from this is the need to consider what the
consequences are for the specification before you add on
innocent-looking details like quotas.

\end{enumerate}

When systems are first developed, they are usually built by people
who don't care about resource limitation issues.  As the system
is used more and gets overloaded, it doesn't break: performance
just degrades to the point where users bail out because they can't
tolerate the poor performance.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Accounting}

Accounting considerations are necessary when you need to allocate 
costs over the user group. The two key elements of accounting
are data collection and billing. We aren't going to discuss billing
at all.

For data collection, the task is relatively simple. You have a CPU that
can count well and can store things. So you decide what it is you want to
count and implement a mechanism to count it.  In the file system the
user might get charged for byte-seconds, for example.

As an aside, an interesting case of different data collection
strategies is found in the comparison of the U.S. and U.K. long
distance telephone billing system.  In the United States, the phone
company keeps a record of what number you called and how long you
talked for, and renders a detailed itemization with each bill.  In the
United Kingdom, no such detailed data is collected.  There is an
"odometer" connected to the phone line. When you dial a long distance
call, the distance of the call determines the rate at which the
odometer is poked. AT the end of the billing periods, you get a bill
for the number of pokes.

But as a general rule, ``accounting is boring''.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Replication}

There are two motivations for making copies of resources: availability
and reliability.

\subsection{Availability}

Availability is provided through the replication of resources.  Dr.
Lampson gave an example, attributed to Jim Grey, of Automatic Teller
Machines (ATMs).  He claims the reason that two machines are generally
found installed side-by-side is not to deal with volume of traffic,
but rather to provide greater availability at the location. In the
event that one of the machines breaks, there is still one left to
service bank customers.

It is desirable to have some relatively automatic method for
fail-over when one resource fails.

\subsection{Reliability}

An example of replication of resources to provide reliability is the
replication of stable storage.  Multiple copies of data are kept in
preparation for inevitable data corruption.

Systems in applications which demand high reliability also use
replication techniques to provide CPU reliability. Multiple systems
may compute a result, then the results can be compared and a majority
vote rendered.

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 which 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}

\section{Management}

Issues that fall into this grouping are termed management
issues for one of the following three reasons:
\begin{itemize}
\item because they are matters of policy
\item because you don't know an algorithm to do them
\item because you were too lazy to code an algorithm to do them
\end{itemize}

The third is claimed to be the most common case.  Note that the issues
discussed here are not claimed to be complete due to the typical lack
of time at the end of class.

\subsection{Naming}

From the point of view of the system manager, every component of the
system that exists and must be managed needs to be named. The basic
mechanism we have seen in the past is our old pal a/b/c/d/e...  The
problems in naming arise because we often don't use the same syntax at
each stage of the name. Currently a large system will use 10 or 20
different namespaces to name users, devices, files, etc.

What does it mean to get to a device through a name? In the file
system, you get an F back from lookup: a well-understood concept.  Dr.
Lampson advocated 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 system could implement an Apply operation: Apply (object,
operation, arguments).

In a large number of cases, Apply looks like RPC: the operation and
arguments are encoded and given to some transport mechanism which
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.

\subsection{Applying Operations}

For certain objects, e.g. a disk track, it may not seem straightforward
to think of the object implementing operations.  Instead, a program
which represents the object may be used for the purposes of applying
operations to the object.

Once you take an object-oriented approach, you can begin to think
about the idea of classes of objects and inheritance of operations.
All this can be viewed in the more familiar context of a window as shown
in Figure~\ref{objfig}.  Here, a window is typically sent a {\em
message} causing it to invoke a {\em method}.  This is equivalent to
the application of an operation.  The windows in subclasses also
inherit methods from their superclass, so a text window would inherit
the ability to grow and add the ability to autowrap text.

\begin{figure}
\centerline{\psfig{width=3.5 in,figure=obj.idraw}}
\caption{Objects exhibiting inheritance.}
\label{objfig}
\end{figure}

There are some generic kinds of operations that all, or at least many,
objects have. Meters that read the state of the object, and knobs that
set the state of the object are generic things that all objects have.
All objects also have dependencies of some sort; the file system
needs the disk(s), for example.  The system manager needs a way of
managing these dependencies.

\subsection{Performance Monitoring}

In performance monitoring, as shown in Figure~\ref{perffig}, you 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 you want the system to tune
itself automatically, then you need a way to implement automatic
feedback.

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

\end{document}