Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

Format of Path-Aliasing Files

Both path-aliasing files share the same format:

  • Blank lines and lines that begin with a # sign are skipped.

  • Each line, other than a blank line or a line preceded by #, must contain four strings separated by any number of blanks or tabs.

    The first string specifies a source path, the second a submit host, the third an execution host, and the fourth the source path replacement.

  • Both the submit host and the execution host strings can be an * (asterisk), which matches any host.

How Path-Aliasing Files Are Interpreted

The files are interpreted as follows:

  1. After qsub retrieves the physical current working directory path, the global path-aliasing file is read, if present. The user path-aliasing file is read afterwards, as if the user path-aliasing file were appended to the global file.

  2. Lines not to be skipped are read from the top of the file, one by one. The translations specified by those lines are stored, if necessary.

    A translation is stored only if both of the following conditions are true:

    • The submit host string matches the host on which the qsub command is run.

    • The source path forms the initial part either of the current working directory or of the source path replacements already stored.

  3. After both files are read, the stored path-aliasing information is passed to the execution host along with the submitted job.

  4. On the execution host, the path-aliasing information is evaluated. The source path replacement replaces the leading part of the current working directory if the execution host string matches the execution host. In this case, the current working directory string is changed. To be applied, subsequent path aliases must match the replaced working directory path.

Example 4-1 is an example how the NFS automounter problem described earlier can be resolved with an aliases file entry.

Example 4-1 Example of Path-Aliasing File

# cluster global path aliases file
# src-path  subm-host   exec-host   dest-path
/tmp_mnt/   *           *           /

Configuring Default Requests

Batch jobs are normally assigned to queues with respect to a request profile. The user defines a request profile for a particular job. The user assembles a set of requests that must be met to successfully run the job. The scheduler considers only those queues that satisfy the set of requests for this job.

If the user does not specify any requests for a job, the scheduler considers any queue to which the user has access without further restrictions. However, grid engine software enables you to configure default requests that define resource requirements for jobs even when the user does not specify resource requirements explicitly.

You can configure default requests globally for all users of a cluster, as well as privately for any user. The default request configuration is stored in default request files. The global request file is located under sge-root/cell/common/sge_request. The user-specific request file can be located either in the user's home directory or in the current working directory. The working directory is where the qsub command is run. The user-specific request file is called .sge_request.

If these files are present, they are evaluated for every job. The order of evaluation is as follows:

  1. The global default request file

  2. The user default request file in the user's home directory

  3. The user default request file in the current working directory


Note - The requests specified in the job script or supplied with the qsub command take precedence over the requests in the default request files. See Chapter 3, "Submitting Jobs," in N1 Grid Engine 6 User's Guide for details about how to request resources for jobs explicitly.


You can prevent the grid engine system from using the default request files by using the qsub -clear command, which discards any previous requirement specifications.

Format of Default Request Files

The format of both the local and the global default request files is as follows:

  • Default request files can contain any number of lines. Blank lines and lines that begin with a # sign are skipped.

  • Each line not to be skipped can contain any qsub option, as described in the qsub(1) man page. More than one option per line is allowed. The batch script file and the argument options to the batch script are not considered to be qsub options. Therefore these items are not allowed in a default request file.

  • The qsub -clear command discards any previous requirement specifications in the currently evaluated request file or in request files processed earlier.

Suppose a user's local default request file is configured the same as test.sh, the script in Example 4-2.

Example 4-2 Example of Default Request File

# Local Default Request File
# exec job on a sun4 queue offering 5h cpu
-l arch=solaris64,s_cpu=5:0:0
# exec job in current working dir
-cwd

To run the script, the user types the following command:

% qsub test.sh

The effect of running the test.sh script is the same as if the user specified all qsub options directly in the command line, as follows:

% qsub -l arch=solaris64,s_cpu=5:0:0 -cwd test.sh


Note - Like batch jobs submitted using qsub, interactive jobs submitted using qsh consider default request files also. Interactive or batch jobs submitted using QMON also take these request files into account.


Previous Previous     Contents     Index     Next Next