Log Rolling and Disk Space Health Check

Log Rolling

StorNext automatically rolls logs via a scheduled cron job to better manage the file system space used by the rolled log files. An additional log rolling cron job will now run frequently to check for and roll “runaway” log files. Additional functionality includes:

• Compression of rolled log files
• Configuration parameters specifically for space management
• Efficient log rolling performance

The configuration parameters include:

• CRITICAL_FILL_LEVEL: If the file system exceeds this fill level (default: 80%), StorNext will remove rolled files to recover space.
• CLEANUP_MIN_SIZE: StorNext will remove rolled files during file system space recovery only if they meet this minimum size (default: 10 MB).

All log rolling configuration parameters are contained in the sn_log_update.cfg configuration file located in the following directory:

Note: StorNext log rolling will not guarantee that the file system will not fill up, given that other non-StorNext files using the same file system may accumulate and fill up the file system. Additionally, the probability exists that a StorNext log may grow at an extraordinarily rapid rate that exceeds the ability for the automatic log rolling to keep up.

StorNext uses a timestamp for the filename extension, instead of a sequential numeric count extension. The rolled files are compressed; a ".gz" extension is appended to the filename. The complete filename format for rolled log files is illustrated in the following example:

You may also configure the log rolling cron job to back up rolled log files to a managed file system. A new storage policy class will be needed, which will require additional media or sdisk space. The size of the data stored will depend on system activity levels.

Note: The default logging configuration saves data for approximately one month, depending on activity levels. Quantum recommends that you keep your log data for a minimum of two years.

The instructions below will back up all rolled logs. Additionally, the MSM and TSM tac log backups will be compressed to approximately 1/20th of their original size before being stored.

Identify the managed file system containing the .ADIC_INTERNAL_BACKUP directory (typically /stornext/snfs1). See the BACKUPFS environment variable in /usr/adic/TSM/config/fs_sysparm to determine the file system name. In the instructions below, change "/stornext/snfs1" as necessary to the name of the managed file system containing the backups.

1. If this is a High Availability (HA) configuration, execute the following command on both MDCs:

2. Execute the following two commands on the active MDC only:

3. Save the existing tdlm crontab so it may be restored if an error occurs while updating the crontab.

4. Execute the following command to edit the tdlm crontab on the active MDC:

5. Append the following text to the end of the existing sn_log_update entry. It is all one continuous line.

   Note: The text begins with a space, and there is a space preceding every hyphen, every occurrence of /usr/adic, and every occurrence of /stornext/snfs1.

There are two locations in cron where you should add or update the text. A complete crontab command is illustrated in the following two examples: