C H A P T E R 5

Releasing

Releasing is the process by which the releaser makes disk cache space available by identifying archived files and releasing their disk cache copy. This makes room for other files to be created or staged from archive media. The releaser can release only archived files. Releasing the file results in a file without any data on the disk cache.

The Sun StorEdge SAM-FS file systems automatically invoke the releaser process when a site-specified disk threshold is reached. In contrast, you can use the `release`(1) command to release a file's disk space immediately or to set releasing parameters for a file. For more information about the releaser process, see the `sam-releaser`(1M) man page.

The releaser contains features that allow you to specify that files be released immediately after archiving, that files never be released, or that files be partially released. The partial release feature is particularly useful because some applications, such as `filemgr`(1), read only the beginning of the file. With partial release, a portion of the file remains on the disk cache and the remainder of the file is released. Reading the first part of the file still on disk cache does not necessarily trigger the staging of the rest of the file back to disk cache from the archive media. These features, and many others, are described in this chapter.

This chapter contains the following topics:

- Releaser Overview

- Theory of Operation

- Definitions

- Partial Release and Partial Stage

- The releaser.cmd File

- The archiver.cmd File's Role in Releasing

- Configuring the Releaser

- Running the Releaser Manually

- Troubleshooting the Releaser

##

Releaser Overview

When file system utilization exceeds its configured high watermark, the file system management software invokes the releaser. First, the releaser reads the `releaser.cmd` file and collects the directives that control the release process. Next, it scans the file system and collects information about each file. Finally, after scanning the entire file system, the releaser begins releasing files in priority order.

The releaser continues to release files as long as the file system remains above the configured low watermark. Typically, the releaser frees enough space to allow the file system to drop below the low water mark. If the releaser cannot find any files to release, it exits. The releaser runs later when more files can be released. While above the high watermark, the file system starts the releaser every one minute.

The high and low watermarks are set with the `high=`percent and `low=`percent file system mount options. For more information about these mount options, see the `mount_samfs`(1M) man page.

##

Theory of Operation

A file system can contain thousands of files. Keeping track of the release priority for all the files can be wasteful because releasing only several large files might return the file system to its low watermark. However, the releaser must examine the priority of each file or risk missing the best candidates for release. The releaser handles this condition by identifying only the first 10,000 candidates.

After identifying the first 10,000 candidates, the releaser discards subsequent candidates if they do not have a priority greater than the lowest-priority candidate among the first 10,000.

After the releaser has determined the priority of the first 10,000 candidates, it selects the files with the highest priority for release. After releasing each file, the releaser checks to see if the file system cache utilization is below the low watermark. If so, the releaser stops releasing files. If not, the releaser continues releasing the files in priority order.

If the releaser has released all 10,000 candidates and the file system is still above the low water mark, it starts over and identifies 10,000 new candidates.

The releaser exits if it cannot find any viable candidates. This can occur, for example, if files do not yet have archive copies. The Sun StorEdge SAM-FS file systems start the releaser again after one minute has elapsed.

##

Definitions

This section explains terms used throughout this chapter.

### Age

The age concept refers to the amount of elapsed time from a given event until now. A file's inode keeps track of the following times that are used by the releaser:

- Residence-change time

- Data-modified time

- Data-accessed time

You can view these times by using the `sls`(1) command with the `-D` option. Each time has a corresponding age. For example, if it is 10:15 a.m., a file with a modify time of 10:10 a.m. has a data-modified age of five minutes. For more information about the `sls`(1) command, see the `sls`(1) man page.

### Candidate

A candidate is a file that is eligible to be released. The reasons why a file would not be a candidate are as follows:

- The file is already offline.

- The file has not been archived.

- The `archiver.cmd` command file specifies the `-norelease` attribute for the file, and the required copies have not yet been made.

- The file is marked as damaged.

- The file is not a regular file. It is a directory, block, character-special file, or pipe.

- The archiver is staging the file to make an additional copy. The file becomes eligible for release after the archiver stages it.

- The age of the file is negative. This usually occurs for NFS clients with inaccurate clock settings.

- The file is marked to never be released. You can use the `release`(1)`-n` command to specify this.

- The file was staged at a time in the past that is less than the minimum residence time setting. For more information, see Specifying a Minimum Residence Time: min_residence_age.

- The file was flagged for partial release, by using the `release`(1) command's `-p` option, and is already partially released.

- The file is too small.

### Priority

A priority is a numeric value that indicates the rank of a candidate file based on user-supplied weights that are applied to numeric attributes of that candidate. The overall priority is the sum of two types of priority: age priority and size priority.

Candidate files with numerically larger priorities are released before candidates with numerically smaller priorities.

### Weight

The weight is a numeric value that biases the priority calculation to include file attributes in which you are interested and to exclude file attributes in which you are not interested. For example, the size attribute of a file is excluded from the priority calculation if the size weight is set to zero. Weights are floating-point values from 0.0 to 1.0.

### Partial release

A file can be partially released by specifying that a beginning portion of the file remain in disk cache while the rest of the file is released. For example, partial release is valuable when using utilities like `filemgr`(1) that read the beginning of a file.

##

Partial Release and Partial Stage

Releasing and staging are complementary processes. Files can be completely released from online disk cache after they are archived, or a site can specify that the beginning of a file (the stub) remain in disk cache while the remainder of the file is released. This ability to partially release a file provides immediate access to data in the file stub without staging the file.

A system administrator can specify both the default partial release size and the maximum size of the stub to remain online when a file system is mounted. The system administrator can set these on the `mount`(1M) command, as follows:

- Specify the `-o partial=`n option to set the default size (n) of a file stub to remain online. The `-o partial=`n setting must be less than or equal to the `-o maxpartial=`n setting. The smallest possible setting is `-o partial=8` kilobytes. The default setting is `-o partial=16` kilobytes.

- Specify the `-o maxpartial=`n option to set the maximum size (n) of a file stub to remain online. To limit the size of the file stub that can be left online, use the `-o` `maxpartial`=n option and specify a size equal to the largest stub that can be left online. To disable the partial release feature, specify `-o maxpartial=0`.

A user can specify the default stub size for a file by specifying the `-p` option on the `release`(1) command or the `p` option on the `sam_release`(3) library routine. To specify different-sized file stubs for different types of files or different applications, a user can specify the `-s` option on the `release`(1) command or the `s` option on the `sam_release`(3) library routine. The `-s` and `s` values must be less than the `-o maxpartial` value used on the `mount`(1M) command when the file system was mounted.

Another mount option, `-o partial_stage=`n, allows a system administrator to establish how much of a partial release stub must be read before the rest of the file is staged. That is, reading past the `-o partial_stage=`n size specification initiates the stage of the file.

By default, the `-o partial_stage=`n option is set to the size of the partial release stub. This value can be configured, though, and it affects file staging as follows:

- If the `-o partial_stage=`n option is set to the size of the partial release stub, the default behavior prevents the file from being staged until the application reaches the end of the partial release stub. Waiting until the end of the stub is reached causes a delay in accessing the rest of the file.

- If the `-o partial_stage=`n option is set to a value smaller than the partial release stub, the following occurs. After the application crosses the threshold set by the `-o partial_stage=`n option, the rest of the file is staged. This reduces the chance of a delay in accessing the rest of the file data.

Example. Assume that the following options are in effect:

- `-o partial_stage=16` (which is 16 kilobytes)

- `-o partial=2097152` (which is 2 gigabytes)

- `-o maxpartial=2097152` (which is 2 gigabytes)

The `filemgr`(1) program is being used, and it reads the first 8 kilobytes of a file. The file is not staged. A video-on-demand program reads the same file, and the file is staged after it reads past the first 16 kilobytes of the file. The application continues reading the 2 gigabytes of disk data while the archive tape is mounted and positioned. When the video-on-demand program reads past 2 gigabytes of file data, the application reads immediately behind the staging activity. The application does not wait because the tape mounting and positioning is done while the application reads the partial file data.

Several command line options affect whether a file can be marked for partial release. Some options are enabled by the system administrator, and others can be enabled by individual users. The following sections describe the release characteristics that can be set by the various types of users.

### System Administrator Option Summary

The system administrator can change the maximum value and default value for partial release when the file system is mounted. The mount(1M) options in TABLE 5-1 affect partial release. For more information about the mount(1) command, see the mount_samfs(1M) man page.

TABLE 5-1 Mount Options for Partial Release
mount(1M) Option | Effect
`-o maxpartial=`n | Determines the maximum amount of space, in kilobytes, that can remain in online disk cache if a file is marked for partial release. The maximum value is 2,097,152 kilobytes, which is 2 gigabytes. The minimum value is 0, which prevents any file from being partially released. If `-o maxpartial=0` is specified, the partial release feature is disabled, released files are released completely, and no portion of a file remains in disk cache. Users cannot override the value specified on this option after the file system is mounted. By default, the n argument is set to 16. This setting enables users to mark files for partial release with the maximum amount remaining on disk being 16 kilobytes.
`-o partial=`n | Sets a default amount of space, in kilobytes, to remain in disk cache if a user marks a file for partial release by using the `release`(1) command's `-p` option. The n argument must be at least 8, but it can be as great as the value specified for the `-o maxpartial=`n option. Because some applications do not need access to the entire file to complete their work, this option can be used to ensure that applications have the needed beginnings of files available to them. At the same time, using this option prevents files from being staged unnecessarily. The default value is `-o partial=16`.
`-o partial_stage=`n | Specifies that when a partially released file is accessed, n bytes of the file must be read before the entire file is staged from the archive media. This value is typically set to be lower than the amount of the `-o partial` setting. For n, specify an integer value from 0 to the `-o maxpartial` specification. By default, this is set to 16, or whatever value was specified for the `-o partial` option.
`-o stage_n_window=`n | Specifies the amount of data to be staged at any one time to n. For n, specify an integer from 64 to 2,048,000. The default is 256 kilobytes. This option applies only to files that have the `stage -n` attribute set.

### User Option Summary

The system administrator sets maximum and default values for the size of a file stub that can remain in disk cache after the file is released. The system administrator also determines whether or not the partial release feature is enabled for a particular file system.

By using the `release`(1) command and the `sam_release`(3) library routines, however, a user can set other release attributes and can specify the files to be marked for partial release. The command and library options that determine partial release attributes are shown in TABLE 5-2. For more information about the `release`(1) command, see the `release`(1) man page. For more information about the `sam_release`(3) library routine, see the `sam_release`(3) man page.

TABLE 5-2 User Release Options
Options | Effect
`release`(1) command and `-p` option or `sam_release`(3) library routine and `p` option | The `-p` and `p` options mark the named file for partial release. If these options are used, the amount of the file remaining in online disk cache after the file is released depends on the value of the `-o partial=`n option that was set when the file system in which the file resides was mounted. These options cannot be used to specify the number of bytes to remain online.
`release`(1) command and`-s partial_size` option or `sam_release`(3) library routine and `s` option | The `-s` and `s` options mark the named file for partial release, and they specify the amount of the file to remain in online disk cache. The arguments to the `-s` or `s` options specify the amount, in kilobytes, to remain online. A user cannot specify that the amount of a file remaining online be greater than the amount specified for the `-o maxpartial=`n value when the file system was mounted. If the user's value is greater than the value for the file system, the value for the file system is used, and the user's specification is ignored.

##

``The `releaser.cmd` File

The `/etc/opt/SUNWsamfs/releaser.cmd` file consists of directive lines that specify site-specific releasing actions. The `releaser.cmd` file can contain directives for setting the release priority, specifying a log file, and other actions.

The following sections describe the `releaser.cmd` directives:

- Specifying Age-Related and Size-Related Release Priority Directives: weight_age, weight_age_access, weight_age_modification, and weight_age_residence

- Specifying Directives for Individual File Systems: fs

- Specifying Debugging Directives: no_release and display_all_candidates

- Specifying a Minimum Residence Time: min_residence_age

- Specifying a Log File: logfile

- Inhibiting Releasing for Rearchived Files: rearch_no_release

- Adjusting the size of the Releaser Candidate List: list_size

For more information about these directives, see the `releaser.cmd`(4) man page.

### Specifying Age-Related and Size-Related Release Priority Directives: `weight_age`, `weight_age_access`, `weight_age_modification`, and `weight_age_residence`

Files are released from a file system using a priority order determined by directives defined in the `releaser.cmd` file. Both file age and file size are considered. By default, sites release the largest, oldest files first, leaving the smallest, newest files on disk. The following sections show how the releaser considers a file's age and size when determining the release priority of files in a file system.

For additional information about releaser directives, see the `releaser.cmd`(4) man page.

#### File Age

The releaser considers the following possible ages when determining the age-related component of a file's release priority:

- The age since it was last accessed

- The age since it was last modified

- The age since it changed residency in disk cache

In some cases, you might want the access age of a file to take precedence over the modification age. In other cases, a simple age derived from the most recently accessed time, modified time, and residence-changed time is preferred.

By default, the age of a file is the more recent of the file's three ages:

- File access age

- File modification age

- File residency age

You can use directives to specify that a weighted age priority be used when calculating the release priority for a file.

CODE EXAMPLE 5-1 shows the age priority directives' formats.

CODE EXAMPLE 5-1 Age Priority Directive Formats
    weight_age = float
    weight_age_access = float
    weight_age_modification = float
    weight_age_residence = float

- The `weight_age` directive specifies that a file's default age (the smaller of the file's access, modification, or residence age) be given a weighting factor. For float, specify a floating-point number in the following range: 0.0`` `` float`` 1.0. By default, float`= 1.0`.

This directive cannot be specified in conjunction with the `weight_age_residence`, `weight_age_modify`, or `weight_age_access` directives.

- The `weight_age_residence`, `weight_age_modify`, and `weight_age_access` directives specify that that a file's age be determined based on a combination of one, two, or three of these possible ages. For float, specify a floating-point number in the following range: 0.0`` `` float`` `` 1.0. By default, float`= 1.0`.

These directives cannot be specified in conjunction with the `weight_age` directive.

If the `weight_age_residence`, `weight_age_modify`, and `weight_age_access` directives are used, the age-related priority for a file is calculated based on a combination of all three ages. First, file age data is gathered for each file's possible age. Secondly, the file age data is multiplied by the weighting factors specified in the `releaser.cmd` file. Finally, the file's age-related priority is calculated by summing the product of the age data multiplied by each weighting factor, as shown in the equation in CODE EXAMPLE 5-2.

CODE EXAMPLE 5-2 Priority Calculation
      file access age * weight_age_access
    + file modification age * weight_age_modification
    + file residency age * weight_age_residence
    _________________________________________________
    = age_related_priority

Example. CODE EXAMPLE 5-3 shows lines in a `releaser.cmd` file that specify that only the file's residence age be considered (and that the modification age and the access age be ignored) when calculating the release priority of a file.

CODE EXAMPLE 5-3 `releaser.cmd` File Fragment
    weight_age_residence = 1.0
    weight_age_modify = 0.0
    weight_age_access = 0.0

After a file's age-related priority is calculated, it is multiplied by the file's size-related priority. The size-related priority is calculated as shown in the following section.

#### File Size

The releaser considers a file's size when determining the size-related component of a file's release priority. The size of the file (in 4-kilobyte blocks) is multiplied by the weight specified for the `weight_size` directive to obtain the size-related component of a file's release priority.

The format of the `weight_size` directive is as follows:

    weight_size = float

For float, specify a floating-point number in the following range: 0.0 float 1.0. By default, float`= 1.0`.

Example. CODE EXAMPLE 5-4 shows a `releaser.cmd` file that specifies that when calculating a file's release priority, a file's size is to be ignored for all files in the `samfs1` and `samfs2` file system.

CODE EXAMPLE 5-4 `releaser.cmd` File
    # releaser.cmd file
    logfile = /var/adm/default.releaser.log
    weight_size = 0.0
    #
    fs = samfs1
    weight_age = 1.0
    logfile = /var/adm/samfs1.releaser.log
    #
    fs = samfs2
    weight_age_modify = 0.3
    weight_age_access = 0.03
    weight_age_residence = 1.0
    logfile = /var/adm/samfs2.releaser.log

### Specifying Directives for Individual File Systems: `fs`

You can use the `fs =` family_set_name directive in the `releaser.cmd` file to indicate that the directives that follow the `fs =` directive apply only to the named file system. This directive has the following format:

    fs = family_set_name

For family_set_name, specify the name of a Family Set in the `mcf` file.

Directives preceding the first `fs =` directive are global and apply to all file systems. Directives following the `fs =` directive override global directives. The directives described in this chapter can be used as either global directive or as directives specific to one file system.

The `releaser.cmd`(4) man page includes examples of the `fs =` directive.

### Specifying Debugging Directives: `no_release` and `display_all_candidates`

The `no_release` and `display_all_candidates` directives can be useful when tuning or debugging the releaser. These directives are as follows:

- The `no_release` directive prevents files from being removed from online disk cache. You can use this directive to check the directives in the `releaser.cmd` without actually releasing files. This directive has the following format:

    no_release

- The `display_all_candidates` directive writes the names of all release candidates to the log file. This directive has the following format:

    display_all_candidates

These directives are helpful when debugging because the releaser writes the names of release candidates to the log file, but it does not physically release them from the file system.

### Specifying a Minimum Residence Time: `min_residence_age`

The `min_residence_age` directive enables you to specify the minimum amount of time that a file must reside in a file system before it becomes a candidate for release. This directive has the following format:

    min_residence_age = time

For time, specify a time in seconds. The default time is 600, which is 10 minutes. There is no practical minimum or maximum time setting.

### Specifying a Log File: `logfile`

If a `logfile` directive is specified in the `releaser.cmd` file, the releaser either appends its activity log to the indicated file name, or the releaser creates the file name if it does not exist. This directive has the following format:

    logfile = filename

For filename, specify the name of a log file.

CODE EXAMPLE 5-5 shows a sample log file (note that some lines have been wrapped to fit on the page).

CODE EXAMPLE 5-5 Releaser Log File Example
    Releaser begins at Wed Apr 28 17:29:06 1999
    inode pathname          /sam1/.inodes
    low-water mark          24%
    weight_size             1
    weight_age              1
    fs equipment ordinal    1
    family-set name         samfs1
    started by sam-amld?    yes
    release files?          yes
    display_all_candidates? no
    ---before scan---
    blocks_now_free:    3481504
    lwm_blocks:         3729362
    ---scanning---
    10501 (R: Wed Apr 21 18:47:50 CDT 1999) 10001 min, 500 blks /sam1/testdir0/filevp
    10500 (R: Wed Apr 21 18:48:10 CDT 1999) 10000 min, 500 blks /sam1/testdir0/filewq
    ...
    ---after scan---
    blocks_now_free:      3730736
    lwm_blocks:           3729362
    archnodrop: 0
    already_offline: 0
    bad_inode_number: 0
    damaged: 0
    extension_inode: 0
    negative_age: 0
    nodrop: 1
    not_regular: 9
    number_in_list: 675
    released_files: 202
    too_new_residence_time: 0
    too_small: 2
    total_candidates: 675
    total_inodes: 1376
    wrong_inode_number: 0
    zero_arch_status: 689
    zero_inode_number: 0
    zero_mode: 0
    CPU time: 2 seconds.
    Elapsed time: 10 seconds.
    Releaser ends at Wed Apr 28 17:29:16 1999

The `releaser`(1M) man page describes the information contained in the log file. Because the size of the log increases with each releaser run, be sure to allow for decreasing the size of the log, or omit the `logfile` keyword.

CODE EXAMPLE 5-6 shows the mathematical relationships that exist among the statistics shown under the`---after scan---` line:

CODE EXAMPLE 5-6 Mathematical Relationships From the `---after scan---` Line in CODE EXAMPLE 5-5
    total_inodes = wrong_inode_number +
    zero_inode_number +
    zero_mode +
    not_regular +
    extension_inode +
    zero_arch_status +
    already_offline +
    damaged +
    nodrop +
    archnodrop +
    too_new_residence_time +
    too_small +
    negative_age +
    total_candidates
       released_files = total_candidates

### Inhibiting Releasing for Rearchived Files: `rearch_no_release`

By default, files marked for rearchiving are released. If the `rearch_no_release` directive is specified in the `releaser.cmd`(4) file, the releaser does not release the files marked for rearchiving. This directive has the following format:

    rearch_no_release

### Adjusting the size of the Releaser Candidate List: `list_size`

You can use the `list_size` directive to specify the number of releaser candidates. If you notice that the releaser makes multiple file system scans before it releases the number of files needed to get to the low water mark, you might want to consider raising this value to a level greater than the default of 10,000. This might be true in a file system that contains many small files. You can get information about releaser activities from the releaser log file. This directive has the following format:

    list_size = number

For number, specify an integer such that 10 number 2,147,483,648.

##

The `archiver.cmd` File's Role in Releasing

Most directives in the `archiver.cmd` file affect archiving, but the archive set assignment directive allows you to specify release attributes that apply to all files in an archive set.

The archive set assignment directive has the following format:

    archive_set_name path [search_criteria ...] directives ...

TABLE 5-3 shows the directives that pertain to releasing.

TABLE 5-3 Archive Set Assignment directives
Directive | Effect
--- | ---
`-release a` | Specifies that the files in the archive set should be released after the first archive copy is made. Do not use this option if you are making more than one archive copy of each file. In such a situation, copy 1 would be be staged in order to make copy 2.
`-release n` | Specifies that the files in the archive set should never be released.
`-release p` | Specifies that the files in the archive set should be partially released after archiving.

For more information about these and the other `archiver.cmd` directives, see Archiving.

##

Configuring the Releaser

It is necessary to decide the characteristics of files in cache for your site. It is wasteful to load a tape if you are staging only a few kilobytes, so you may want to bias your system to retain small files in cache. CODE EXAMPLE 5-7 shows the directives to use in the `releaser.cmd` file to release the largest files first.

CODE EXAMPLE 5-7 Directives to Release the Largest Files First
    weight_size = 1.0
    weight_age = 0.0

Alternately, you may want to retain recently modified files in cache since a recently modified file might be modified again soon. This avoids the overhead created when the file is staged to enable modification. In this case, use the second set of age weights. CODE EXAMPLE 5-8 shows the directives to use in the `releaser.cmd` file to weight files in strict order starting with the oldest modified to the most recently modified.

CODE EXAMPLE 5-8 Directives to Release Oldest-Modified Files First
    weight_size = 0.0
    weight_age_access = 0.0
    weight_age_modify = 1.0
    weight_age_residence = 0.0

However, as the following examples demonstrate, most situations are not this straightforward.

Example 1. Assume that you want to release the largest files first. There are hundreds of small files that are the same size, and there are several large files. The cumulative size of the small files might exceed the size of the single, largest file. Eventually, the releaser releases all the large files. If `weight_age = 0.0` is specified, the releaser releases the small files in essentially random order because they are all the same size and have the same release priority.

In this scenario, you could set `weight_age = 0.01` as a tiebreaker. The releaser would release the older of two equally sized files first.

Example 2. This example presents a better method to specify how to release the largest files first.

Set `weight_size = 1.0` and `weight_age = 0.01`.

These directives violate the largest-first policy by counting smaller, less recently accessed files as better candidates than larger, more recently accessed files. You can make this effect as small as you want by making `weight_age` smaller than `weight_size`. For example, based on the previous settings, a 4-kilobyte file that staged 100 minutes ago and an 8-kilobyte file that just staged both have the same release priority.

The releaser randomly chooses a file to release. If it chooses a 4-kilobyte file, it violates the largest-first intent. Setting `weight_age` considerably smaller (for example, to 0.001) reduces this effect. If a 4-kilobyte file staged 1,000 minutes ago, it has the same priority as the 8-kilobyte file that just staged.

You can use the `no_release` and `display_all_candidates` directives and run the releaser manually to obtain a list of candidates in priority order for use in adjusting the priority weights.

##

Running the Releaser Manually

From time to time, you might want to run the releaser manually. For this, you need to know the mount point of the file system and the low watermark the releaser should attempt to reach.

For example, to release files in the `/sam1` file system until it reaches 47 percent full, log in as root and type the following:

    # /opt/SUNWsamfs/sbin/sam-releaser /sam1 47 1.0

The final argument, `weight-size`, is overridden by a `weight_size` command in the `releaser.cmd` file. As the releaser runs, it writes information to your screen and to the releaser log file (if specified in the `releaser.cmd` file.) For more information, see the `sam-releaser`(1M) man page.

##

Troubleshooting the Releaser

There can be several reasons for the releaser to not release a file. Some possible reasons are as follows:

- Files can be released only after they are archived. There might not be an archive copy. For more information about this, see Why Files Are Not Archiving.

- The archiver requested that a file not be released. This can occur under the following conditions:

- The archiver has just staged an offline file to make an additional copy.

- The `-norelease` directive in the `archiver.cmd` file was set and all the copies flagged `-norelease` have not been archived. Note that the releaser summary output displays the total number of files with the `archnodrop` flag set.

- The file is set for partial release, and the file size is less than or equal to the partial size rounded up to the disk allocation unit (DAU) size (block size).

- The file changed residence in the last min_residence_age minutes.

- The `release -n` command has been used to prevent directories and files from being released.

- The `archiver.cmd` file has the `-release n` option set for too many directories and files.

- The releaser high watermark is set too high, and automatic releasing occurs too late. Verify this in the `samu`(1M) utility's `m` display or with SAM-QFS Manager, and lower this value.

- The releaser low watermark is set too high, and automatic releasing stops too soon. Check this in the `samu`(1M) utility's `m` display, or with SAM-QFS Manager, and lower this value.

- Large files are busy. They will never reach their archive age, never be archived, and never be released.

Copyright © 2004, Sun Microsystems, Inc. All rights reserved.