glass@mica.berkeley.edu (07/29/89)
I've been asked to write an essay on how clusters of diskless
UNIX workstations manage to share file systems -- without
stepping on one another's "toes" and maintaining their individual
identities.
There are two issues here. The first is: How do manufacturers
arrange the file system so that the files which give the machines
their individual identities appear different to each machine,
while others are shared? Remember that, due to the ad-hoc growth
of UNIX, many configuration files are in the same directories as
data files, utilities, and applications that can and should be
shared.
Second, how does a server handle diskless clients with different
architectures (or running different versions of the OS)? For
example, a Sun 4 can't use the same binaries as a Sun 3 -- and if
the server is a VAX, it will need separate binaries as well.
I've begun to get a handle on how Sun addresses this problem in
SunOS 4.0 (though more info would be welcome). However, I have no
idea how (or if) Apollo, ULTRIX, HP, Sequent (which really is a
network in a box), AIX, A/UX, POSIX, and OSF propose to handle
these problems. (I have heard that the Apollo machines implement
some trick whereby environment variables can be included in the
pathnames of files, but the person who mentioned this to me
didn't know any of the details, nor how pervasive this technique
was.)
If you have insights on how any or all UNIX implementations
address these problems, please respond to this posting and/or
send me mail. I'm sending this query to a broad cross-section of
newsgroups in an attempt to learn about many different
techniques, but since following up to all those groups would
cause a great deal of traffic, I've set the Followup-To: line to
point at comp.unix.questions. I will summarize (and perhaps
interject some ideas) in the essay, which I hope to publish
shortly.
============================================================================
"One of the nicest things about mathematics, or anything else you might
care to learn, is that many of the things which can never be, often are."
Norton Juster, "The Phantom Tollbooth"
============================================================================glass@mica.berkeley.edu (07/29/89)
I've been asked to write an essay on how clusters of diskless
UNIX workstations manage to share file systems -- without
stepping on one another's "toes" and maintaining their individual
identities.
There are two issues here. The first is: How do manufacturers
arrange the file system so that the files which give the machines
their individual identities appear different to each machine,
while others are shared? Remember that, due to the ad-hoc growth
of UNIX, many configuration files are in the same directories as
data files, utilities, and applications that can and should be
shared.
Second, how does a server handle diskless clients with different
architectures (or running different versions of the OS)? For
example, a Sun 4 can't use the same binaries as a Sun 3 -- and if
the server is a VAX, it will need separate binaries as well.
I've begun to get a handle on how Sun addresses this problem in
SunOS 4.0 (though more info would be welcome). However, I have no
idea how (or if) Apollo, ULTRIX, HP, Sequent (which really is a
network in a box), AIX, A/UX, POSIX, and OSF propose to handle
these problems. (I have heard that the Apollo machines implement
some trick whereby environment variables can be included in the
pathnames of files, but the person who mentioned this to me
didn't know any of the details, nor how pervasive this technique
was.)
If you have insights on how any or all UNIX implementations
address these problems, please send mail. I will summarize (and
perhaps interject some ideas) in the essay, which I hope to
publish shortly.
============================================================================
"One of the nicest things about mathematics, or anything else you might
care to learn, is that many of the things which can never be, often are."
Norton Juster, "The Phantom Tollbooth"
============================================================================decot@hpisod2.HP.COM (Dave Decot) (08/01/89)
CCCCDDDDFFFF((((4444)))) CCCCDDDDFFFF((((4444))))
NNNNAAAAMMMMEEEE
cdf - context dependent files
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
A context dependent file (CDF) consists of several files
grouped under the same path name. The system ordinarily
selects one of the files using the context of the process
(see _c_o_n_t_e_x_t(5)). This mechanism allows machine dependent
executable, system data and device files to work correctly
from all nodes in a cluster while using the same path name.
A CDF is implemented as a special kind of directory, marked
by a bit in its mode (see _c_h_m_o_d(2)). The name of the CDF is
the name of the directory; the contents of the directory are
files with names that are expected to match one part of a
process context. When such a directory is encountered
during a path name search, the names of the files in the
directory are compared with each string in the process's
context, in the order in which the strings appear in the
context. The _f_i_r_s_t match is taken to be the desired file.
The name of the directory thus refers to one of the files
within it, and the directory itself is normally invisible to
the user. Hence, the directory is called a _h_i_d_d_e_n
_d_i_r_e_c_t_o_r_y.
When a process with a context that does not match any file
names in the hidden directory attempts to access a file by
the path name of the hidden directory, the reference is
unresolved; no file with that path name appears to exist.
When such a process attempts to create a file with the path
name of the hidden directory, it creates within the hidden
directory a file whose name is the cnode name from the
process's context.
A hidden directory itself can be accessed explicitly,
overriding the normal selection according to context, by
appending the character '+' to the directory's file name.
EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
Consider a cluster with three versions of ////eeeettttcccc////iiiinnnniiiittttttttaaaabbbb: one
for cnode ``william'', one for cnode ``david'' and a common
file for the rest of the cnodes. The contents of the hidden
directory ////eeeettttcccc////iiiinnnniiiittttttttaaaabbbb, as shown by the command:
ls -l /etc/inittab+
would then be:
-rwxr-xr-x 1 root other 1416 Mar 7 10:08 david
-rwxr-xr-x 1 root other 1211 Apr 12 11:16 default
-rwxr-xr-x 1 root other 1037 Apr 3 12:04 william
Hewlett-Packard Company - 1 - Jul 31, 1989
CCCCDDDDFFFF((((4444)))) CCCCDDDDFFFF((((4444))))
The file names ``william'' and ``david'' will match the
cnode name in the context of all processes on those cnodes.
The file named ``default'' matches all contexts if no other
file in the hidden directory matches, and thus matches the
contexts of all processes on other cnodes. While a
``default'' file may appear in a hidden directory, it is not
necessary to have one. If it did not exist in this case,
nodes other than ``william'' and ``david'' would not see any
file named ////eeeettttcccc////iiiinnnniiiittttttttaaaabbbb.
If a user on the cnode ``william'' wants to find the
difference between the local cnode's ////eeeettttcccc////iiiinnnniiiittttttttaaaabbbb and the
default version, any of the commands:
diff /etc/inittab /etc/inittab+/default
diff /etc/inittab+/william /etc/inittab+/default
or
cd /etc/inittab+ ; diff william default
will refer to the appropriate files.
A directory is changed to a hidden directory using _c_h_m_o_d(1).
In the above example, if ////eeeettttcccc////iiiinnnniiiittttttttaaaabbbb were an ordinary
directory,
chmod +H /etc/inittab
would be used to make it a hidden directory. Invoking:
chmod -H /etc/inittab+
would make ////eeeettttcccc////iiiinnnniiiittttttttaaaabbbb appear as a regular directory. Note
that the '+' must appear so that the mode will be changed
for the hidden directory itself.
A hidden directory may contain files of any type, including
other CDFs. Such use of nested CDFs is preferable to
relying on the order of items in the context for selecting
files from a single hidden directory. For example, in a
cluster of HP9000 Series 300 workstations some of the
workstations might have HP98248A floating point
accelerators, and one of those, with a cnode name of
``color'', might have a different graphics display. If
////uuuussssrrrr////llllooooccccaaaallll////bbbbiiiinnnn////ggggrrrraaaapppphhhhiiiiccccsssspppprrrroooogggg is a floating point intensive
application that uses the local graphics display, it might
be useful to have three versions built for the appropriate
hardware configurations. The arrangement of the three
versions, as shown by the command:
Hewlett-Packard Company - 2 - Jul 31, 1989
CCCCDDDDFFFF((((4444)))) CCCCDDDDFFFF((((4444))))
ls -lRH /usr/local/bin/graphicsprog+
might then be:
total 202
dr-sr-xr-x 2 bin bin 1024 Feb 26 17:34 HP98248A+
-r-xr-xr-x 1 bin bin 101144 Feb 26 17:31 default
graphicsprog+/HP98248A+:
total 414
-r-xr-xr-x 1 bin bin 105112 Feb 26 17:34 color
-r-xr-xr-x 1 bin bin 103732 Feb 26 17:40 default
AAAAUUUUTTTTHHHHOOOORRRR
_C_d_f was developed by HP.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
chmod(2), chmod(1), context(5), find(1), getcdf(3C),
getcontext(2), getcontext(1), ls(1), pwd(1), makecdf(1M),
showcdf(1), tar(1).
Hewlett-Packard Company - 3 - Jul 31, 1989