How the Common Directories Are Organized?

First a warning: Often the current state falls short of this ideal, because many principles have matured after the first installations. This page describes the requirements the future installations.

General Design Principles

There are six sorts of directory locations:

  1. low-level: directories that start with /fs/ or /mnt/ should never be user for specifying resource locations
    • /fs/corpus3/ - a file system containing all local the language bank directories
    • /fs/corpus/ - a symbolic link to /fs/corpus3/
    • /fs/linux/ - a file system containing various linux versions
    • /fs/gen/ - a file system containing files of a generic nature (such as manuals and data)
    • /fs/src/ - a file system containing source files
    • /fs/kielipankki/ - a file system containing the language bank data directories
    • /fs/metawrk/ - a file system that contains large work directories
  2. slash-directories: directories on a non-root partition that are used to extend the root directory with /v/, /p, and c
    • /fs/corpus/slash-p/ - a directory containing directory /p/
    • /fs/corpus/slash-c/ - a directory containing directory /c/
    • /fs/corpus/slash-v/ - a directory containing directory /v/
  3. install directories: contains software that depends on a particular system version; should be used while installing the software
    • /v/linux24_i386/ is a directory whose content is mainly compatible with Linux RedHat 4(Nahant Update 4 2.6.9-42.0.3.EL i686), the current system of the corpus3.csc.fi machine.
    • /v/linux22_i386/ is a directory whose content is less compatible with the system
    • /v/gen/ is a directory whose content is compatible with almost any system at CSC
    • /usr/local/contrib/appl/ling/username/software/version/ is a directory that contains one particular version of the software
  4. views: directories such as /p/ and /usr/local/bin, should contain symbolic links to installed software
    • /p/ contains links to /v/ and abstracts away from its the system version; contains a standard view to /v/; hides the architecture and system version and presents a structure that can be used to access system-dependent versions through system-independent alias locations.
    • /l/ contains links to v/ and abstracts away from its the system version; contains a server-specific view of /v/
  5. shortcuts and aliases: These create alternative or shortened paths as
    • /corp/ is a compatibility shorthand for accessing /usr/local/uhling/corp/
    • /usr/local/contrib is a conventionalized alternative for our /c/
  6. temporary working areas:
    • $TMPDIR i.e. /tmp/
    • /var/
    • /usr/tmp/
    • $WRKDIR i.e. /wrk/username a directory that contains user's local, machine specific working area. The files may be recycled automatically if the files are older than 7 days.
    • $METAWRK i.e. /fs/metawrk/username/= - stores files for 30 files
    • $HOME - available till the termation of the user's customer agreement with CSC
    • $ARCHIVE - available till the termation of the user's customer agreement with CSC.

Where the software is to be installed?

Often configuration scripts store the installation location to some internal variables of the software. For this reason, it is necessary to choose to have it set in a way that works with minimum amount of extra work in additional machines in CSC.

The existence of /v/ is primary while /p/ and /usr/local/appl/ are secondary

All machines can share same /v/ -locations if the necessary filesystems have been mounted to them, but not all locations in the /v/ tree need to be included to the /p/ view of it. And even if there is a link in the /p/ tree, it would be useless if its target does not exist. Thus /v/ is alway more important than /p/.

The directory names in /v/ are better fixed than the names in /fs/ or /mnt/

Software is always installed to an install directory that should exists in the first place in all CSC machines, rather than to directories that are dependent on the mount point (such as /fs/corpus3) or on the view (such as /p/bin/). There are two main locations of this type: /v/ and /c/ trees. The first is writable by the CSC staff only but the latter is available for all contributors. It is an error to install software to a low-level directory or to tell the users about a location of software using a low-level directory. The reason is that CSC reserves the right to change low-level directories overnight. For example, /fs/corpus3/ used to be /mnt/corpus2/. It may happen that such changes break the backwards-compatibility.

There are two install directories

  • The existence of /v/ is CSC-wide, while the views presented by the /p/ and /usr/local/ may not cover all the machines of CSC because all links pointing to the /v/ directory tree must be added manually to the directories under /p/ and /usr/local/. This is, thus, a simple reason, why all the software should be installed to the /v/ -tree, rather than to such unsatisfactory locations as /usr/local/, /l/, or /mnt/corpus/appl/ling/.

  • Experienced users have the right to write to directories of the form /usr/local/contrib/appl/field/username/ where field can be e.g. ling and username can be e.g. ylijyra. The user may install several versions of the same program. Under the username directory, the user should create a directory named by the software, and its subdirectory named by the version of the software. Under the assumption that two systems need different versions, the /c/ tree may contain installations for multiple architectures and linux-versions. The user is responsible for indicating which version runs in which machine. This can be done e.g. in a README-file put to /usr/local/contrib/appl/field/username/program/.

A conceivable exception

  • In some special cases, the software installs itself to some standard location, such as /usr/local/textlive/, and changes to this installation location may be risky. While the correct installation location would be in /v/ tree, it may be possible to configure the software for /usr/local/textlive/ (or leave it as the default). The only misadvantage of this arrangement is that the software cannot be run in a machine if it does not implement a link from a view directory such as /usr/local/textlive/ to the physical of the software in location in /v/.
  • There may be wrongly installed software. We do not need to reinstall them to the /v/ tree, but we might want to do so in the ideal world. We can also move software from view directories to the /v/ tree and add a link to the original location in a view directory, but this would require a README or more to tell that the software has been configured wrongly for a view directory.

Some corpus.csc.fi -specific slash-directories as low-level directories

directory real location
/v/ /fs/corpus/slash-v/
/p/ /fs/corpus/slash-p/
/l/ /fs/corpus/slash-v/
/opt/ /fs/corpus/slash-opt/
/wrk/ /fs/corpus/slash-wrk/
/f/ /fs/corpus/slash-f/

Some important install directories of /v/

directory function
/v/linux24_i386/appl/ CSC-wide installations of application programs for linux24_i386 systems
/v/linux24_i386/appl/ling/ CSC-wide installations of linguistic software
/v/linux24_i386/appl/lang/sicstus/ CSC-wide installation of the SICStus Prolog
/v/gen/appl/texlive/ Location for storing TeXLive (we do not know whether we can use this a the install directory

Some important subdirectories of /usr/local/ and /l/

directory function
texlive/ A symbolic link to /v/gen/appl/texlive/
appl/ A symbolic link to /v/linux24_i386/appl/ that contains applications maintained by CSC.
bin/ Server-specific executables for scientific computing. Contains symlinks to binaries in /usr/local/appl/
contrib/ A base directory reserved for installations contributed by the users. A symbolic link to /c/
kielipankki/ A base directory reserved for the linguistic resources maintained by CSC.
kotus/ A base directory reserved for the Research Institute for the Languages of Finland.
uhling/ A base directory reserved for the University of Helsinki Corpus Server (UHLCS) directories.

Some important compatibility shortcuts

/korpus/ includes symlinks to the subdirectories of /usr/local/kotus/korpus/ (for compatibility)
/corp/ includes symlinks to the subdirectories of /usr/local/uhling/corp/ (for compatibility)
/proj/ includes symlinks to the subdirectories of /usr/local/uhling/proj/ (for compatibility)
/mnt/ includes symlinks to the subdirectories of /fs/ (for compatibility; now all mounts are file server mounts to /fs/, while mounts used to be local and in /mnt/)

Questions and Answers

 

-- AnssiYliJyra - 16 Sep 2006

Topic revision: r11 - 2006-12-20 - AnssiYliJyra
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback