Global Home Filesystem

Overview

Global home directories (or "global homes") provide a convenient means for a user to have access to source files, input files, configuration files, etc., regardless of the platform the user is logged in to. Wherever possible, you should refer to your home directory using the environment variable $HOME. The absolute path to your home directory (e.g., /u4/elvis/) may change, but the value of $HOME will always be correct. For security reasons, you should never allow "world write" access to your $HOME directory or your $HOME/.ssh directory. NERSC scans for such security weakness, and, if detected, will change the permissions on your directories.

Platforms Utilizing Global Home

The Global Home file system is available on all NERSC systems except PDSF. It is expetcted that all future NERSC systems will use global homes.

Quotas and Performance

Default global home quotas are 40 GB and 1,000,000 inodes. Quota increases in global homes are approved only in extremely unusual circumstances; users are encouraged to use the various scratch, project, and HPSS storage systems for large data.  If you believe you have a legitimate need for a larger global home quota, please fill out the Disk Quota Change Request Form.

Performance of global homes is optimized for small files. This is suitable for compiling and linking executables, for example. Home directories are not intended for large, streaming I/O. User applications that depend on high-bandwidth for streaming large files should run in Scratch (Global or Local) or Project.

Purging and Backups

Files in global homes are not subject to purging.

Global homes are backed up to HPSS on a regular basis.  If you require a restoration of lost data, please contact NERSC Consulting with pathnames and timestamps of the missing data.  Such restore requests may take a few days to complete.

IMPORTANT: All NERSC users should back up important files to HPSS on a regular basis.  Ultimately, it is the users' responsiblity to protect themselves from data loss.

Dot-files

Global home directories are pre-populated with startup files (dot-files) for all supported shells. The "standard" dot-files are symbolic links to read-only files that NERSC controls. For each standard dot-file, there is a user-writable ".ext" file. For example, C-shell users are generally concerned with the files .login and .cshrc, which are read-only at NERSC. These users should put their customizations in .login.ext and .cshrc.ext.

Users may have certain customizations that are appropriate for one NERSC platform, but not for others. The .ext files all have examples of how to do this, by testing the value of the environment variable $NERSC_HOST. For example, on Carver the Intel Fortran compiler is called ifort. A C-shell user might include the following in their .cshrc.ext file:

Occassionally, a user will accidentally delete the symbolic links to the standard dot-files, or otherwise damage the dot-files to the point that it becomes difficult to do anything. In this case, the user should run the command /usr/common/usg/bin/fixdots. This command will recreate the original dot-file configuration, after first saving the current configuration in the directory $HOME/KeepDots.timestamp, where timestamp is a string that includes the current date and time. After running fixdots, the user should carefully incorporate the saved customizations into the newly-created .ext files.

Usage Across Multiple Platforms

Many users maintain application codes in their home directories. This usually consists of a set of source files, configuration files and makefiles or scripts, object files and libraries, and executable files. In addition, there might be sample input and output files for testing.

Global homes provide a mechanism where users can maintain a single copy of files that are machine independent (source files, input files, etc). Users should arrange that machine-dependent files (object files, executables, etc) are placed in separate directories. One obvious way is to create subdirectories in the global home directory, each named after a particular NERSC system.

Another way is to make a directory per application and make specific system sub-directories