Migration problems

Description

All migrations are waiting for OpenArchive (OA) disk buffer and data transfers to OA media do not start.

Explanation

If OA jobs are aborted, killed or they die for an unknown reason, it may happen that the temporary data which they create is not automatically removed, but is left in the OA disk buffer, occupying valuable storage space. In such situations, OA jobs will report OA disk buffer as being full in the OA event log. The jobs will remain in the waiting state and none of them will start writing to tape.

Workaround

If this happens, the solution is to restart OA processes on the consolidated OA system or OA server using the ivd --restart command. At the OA startup, Resource Manager automatically removes all data from the file systems assigned to the OA disk buffer.

Description

Files are not migrated because the file system ran out of free space.

Explanation

The OA implementation stops migrating files if a file system for OA databases and system files runs out of free space.

Mount point of the file system for OA databases and system files is /var/opt/ivd.

Workaround

Under special circumstances, such as when there are many small files or many changes of file properties, Fast Recovery Information (FRI) requires a large amount of disk space. You need to dedicate enough disk space for the belonging file system for OA databases and system files to prevent it from running out of free space. This is potentially dangerous since it may result in corrupt FRI files. You can prevent this by calculating the expected FRI size and dedicating enough disk space for the file system holding temporary FRI data files. Use the following formula to calculate the expected FRI size:
where the meaning of the parameters is:
Sfri ..... estimated maximum size of FRI files on disk.
Nv ..... total number of open OA medium volumes in the OA implementation. This number is determined by the number of configured OA media pools that contain media with migrated files.
Sv ..... size of an OA medium volume on tape.
Sf ..... average size of files being migrated.
Lf ..... average filename length of files being migrated.
Nm ..... average number of files migrated in the same migration job.
Tbks ..... block size on tape medium. This factor is only applicable if all OA media pools are configured with the same block size.
[x] ..... the value in the brackets rounded up to the nearest integer.
Sfri Nv × Sv ×[(350 + Lf)× Nm ⁄ Tbks]
[Sf × Nm ⁄ Tbks]
= ----------------------------------------------------------------------------------------------

Description

After a migrated file is modified using a third-party application, its new generation is
migrated using a different file ID.

Explanation

The cause for this problem is the way the third-party application is handling the modification process. Such application creates a copy of the current file first and then modifies the copy instead of the original. After the copy is saved, the application renames the copy with the original filename and thus replaces the original. Examples of applications that use this approach to handle open files are vi (plain text editor) and Microsoft Word.

Workaround

Older generations of a file that was edited in such an application can be retrieved only using their file ID. To display the list of all migrated file generations, enter:
ivdfile --history FileName
In the command output, search for a particular file generation and determine its file ID. Run the following, specifying the file ID:
ivdfile --recall --id PartitionName FileID [--into Path]

Description

Running the commands ivdfile --migrate and ivdfile --trigger-migration in sequence does not start migration job.

Explanation

ivdfile --migrate does not add files to the migration list, but rather to the dirty file list. As the ivdfile --trigger-migration command only considers the migration candidate list, running it shortly after the file was added to the dirty file list does not have the desired effect.

Workaround

When a file is added to the dirty file list, you should wait until the minimum file age interval expires before running ivdfile --trigger-migration. This interval is defined by the MinFileAge variable in the migration policy of the respective OA partition.

Description

Changing partition configuration parameters does not affect files on dirty list.

Explanation

If the MinFileAge parameter is modified to a high value and then back to a lower value, the results only come into effect after the expiry of the higher MinFileAge for the first time. After the expiry of the higher MinFileAge then the new (lower) value is used from that point on.

Workaround

Wait for the higher MinFileAge to expire or remount the HSMFS that is affected.

Description

After starting OA daemons (services) with the command ivd --start, the following error appears in the OA error log:
ERROR: *** NO OWNER set for INO... *** File must be migrated again! fileID= <FileID> file <DirectoryPath>/<FileName>

Explanation

While OA daemons (services) on a particular OA client are stopped and modifications are made on an HSM file system located on the client, it may happen that a file system event is lost. The file owner information for the file DirectoryPath/Filename in the HSMDB is not complete. This error can be detected earlier using ivdcheck --fsc-hsmfs, and is logged when the migration of the file is started.

Workaround

Manually put the file and the directory where the file is located on the migration candidate list using the command ivdfile --migrate DirectoryPath Filename.

Description

Migrations are not started, and the corresponding migration jobs remain queued with their statuses set to 'waiting for resources' or 'pending'.

Explanation

The most probable cause for this problem is shortage of the secondary storage space. You need to configure additional tape media or disk media in the appropriate OA media pools, depending on the configuration of your OA implementation.

Workaround

For problem resolution information, see chapter ”Monitoring and maintaining ivd”, section ”Extending the secondary storage space” on page 227.