This ``tip of the week'' describes in some detail how the filesystems are organized at math. It is fairly technical. After reading this you will have some idea how to change directories into packages such as the matlab toolboxes, lisp documentation, &tc., and an appreciation for design of our setup. Most machines in our network do not have much, if any, local disk space: instead, disks are made to appear local via a protocol call the ``Network File System'' or NFS. Making a remote (or local) disk appear on the local computer's directories is termed ``mounting'' a directory. Math.ufl.edu now uses a sophisticated ``automounter'' program that figures out which computer on the network has the program or files you wish to access. The automounter mounts the proper directory on your local computer only as needed: if you enter the command ``ls /depot/images'', there will be a noticeable pause as the automounter figures out where on the network that directory is and requests the remote computer to provide access via an NFS mount request. When you are finished using the mounted directories, the automounter unmounts them very quickly. In fact, your home directory is treated in this way: it is normally not available on the computer until you attempt to access your files during the process of logging in. On logging out, your directories are quickly unmounted. Why use an automounter? It is to help ensure that if a remote computer from which some directories are mounted goes down (or if an intervening gateway experiences problems) you will not experience a ``hang'' while your computer attempts, and reattempts, to connect to the problem computer. These hangs (a typical message is ``NFS Server foobar not responding'') can take up to 15 minutes to timeout. Since we have some 21 directories for user accounts spread around the department, and 27 special purpose software packages similarly distributed, you can see that the potential for one computer to wreak havoc is very real. The use of an automounter greatly diminishes this risk. Ah, the downside: If you wish to browse through these specially mounted directories, you will have to access a file directly by name. This can be very confusing. Try the following (the ``%'' implies you are at a shell prompt, do not type it in): % ls /home and you'll see, perhaps, a single directory: lab0 now try % ls /home/fac9 and you will see: fischer/ hager/ lost+found/ Try the top level /home directory again: % ls /home and you see that directory /home/fac9 has appeared: lab0 fac9 And that is crux of the problem: you need to know the names of automounted directories first, it is impossible to discover them by just doing directory listings. So...there are some conventions we have used in naming packages, both for the system and for people who might wish to browse through the system. All packages exist under the directory /depot// where is the name of the software package. The executable programs exist under the special directory /depot//bin/ and libraries under /depot//lib/. These two directories are in general different for Sparc vs. Sun3 machines, since they hold executable machine code specific to the two different architectures. All files that can be shared between machines is kept under the directory /depot//share/, so in this directory you will find documentation, manual pages, tutorials, and so on. Here is a list of current packages and a description of their contents: J/bin The J programming language J/share J tutorials X11R5/bin X11 programs X11R5/include C header files X11R5/lib X11R5/share startup, configuration files, etc akcl/bin Common lisp bands akcl/lib akcl/share source code, docs, emacs help. andrew TBA cayley/bin cayley executable cayley/lib cayley (ascii text) programs cayley/share manpages, userquide (tex and dvi) cdrom our cdrom, when mounted, appears here cmucl/bin CMU common lisp cmucl/lib cmucl/share documentation Collect miscellaneous documentation games/bin games. games/lib games/share gnu/bin Gnu software (gcc, shell utilities) gnu/lib gnu/share haskell/bin Haskell logic programming language haskell/share images World-writable directories for pics khoros/bin visual programming language khoros/lib khoros/share macsyma/bin macsyma symbolic programming macsyma/lib macsyma/share mail where incoming mail is mounted man collect /depot/ manpages maple/bin maple package maple/lib maple/share matlab/bin matlab package matlab/etc system management for matlab matlab/lib matlab/share openwin/bin Sun's version of X-windows openwin/demo demo programs openwin/etc system management programs openwin/include C header files openwin/lib machine code libraries openwin/share manpages, etc, pvm/bin Parallel virtual machine pvm/lib pvm/share how-to notes and example source scheme-to-c/bin DECWRL scheme scheme-to-c/lib scheme-to-c/share src Collected miscellaneous source code sundry-imaging/bin miscellaneous image processing tools sundry-imaging/lib sundry-imaging/share sundry-math/bin miscellaneous math programs sundry-math/lib sundry-math/share tmp world writable temp space wais/bin wide area information server wais/lib wais/share One more point here: The /depot//bin directories are not directly on your path. If they were, then when you logged in, each and every package would be mounted on your local machine as your shell searched for exectuables on your path, a very slow process. Instead, a series of directories under /math are created by theme: there is a /math/algebras/ directory, a /math/languages/ and a /math/imaging/ directory. In each directory a series of symbolic links is created to the appropriate /depot//bin directory. Try ``ls -l /math/algebras'' to see an example. These symbolic links are local to the machine you are on, and the links (not the files they point to) are checked by your shell. Thus, programs are made known to your operating environment, but do not cause NFS mounts until they are actually run. Not all packages are directly available: if you want to use Sun's openwindows, you must place it on your path yourself (and take out /depot/X11R5/bin!) /depot/khoros/bin and /depot/pvm/bin directories are treated similarly. If you wish to see what the automounter is actually doing, try using the command ``/usr/local/etc/amq'' (the long pathname is necessary as this directory is not on most user's paths). Checking the manpages on ``amd'' and ``amq'' will be useful as well. This admittedly convoluted system has helped make our extremely distributed environment the most robust and trouble-free Unix installation on campus. Randy Fischer Subject: file system