![]() |
![]() |
[ | | | ]
To keep your local file systems synchronized with the Tivoli Storage Manager server that you contact for space management services, the HSM client automatically reconciles your file systems at intervals that you set. You, as root user, also can start reconciliation manually.
This chapter describes the reconciliation options that you set, the reconciliation tasks that the HSM client performs, and the manual performance of these tasks.
The HSM client automatically reconciles each file system for which space management is active. To specify how often reconciliation runs, modify the setting on the reconcileinterval option in your dsm.sys file. The default is every 24 hours. To specify how many file systems automatically are reconciled at one time, modify the setting on the maxreconcileproc option in your dsm.sys file. The default is three file systems.
When you modify or delete a migrated or premigrated file from your local file system, an obsolete copy of the file remains in storage. During automatic reconciliation, any obsolete copies of your migrated or premigrated files are marked for expiration. When the copies expire, they are removed from the server. To specify how many days a migrated or premigrated file remains in storage after you recall and modify or erase it from your local file system, modify the setting on the migfileexpiration option in your dsm.sys file. The default is seven days.
For more information about these options, see "Using Options".
Table 14 describes the tasks that automatic reconciliation performs
on files and file systems.
Table 14. Reconciliation Tasks
Object | Reconciliation Tasks |
---|---|
Migrated files |
|
Premigrated files |
|
Stub files | Records, in the orphan.stubs file, the name of any file for which a stub file exists on your local file system, but a migrated file does not exist in storage. See "Resolving Orphaned Stub Files" for more information. |
Premigrated files database | Valid for AIX JFS only
|
Status file | Updates the following information in the status file:
|
You can perform reconciliation tasks manually for one or more file systems, or synchronize your client and server only. The sections that follow describe each task. For example, if you recall a large number of migrated files, modify them, and selectively migrate them to storage, two copies of each file reside in storage. The unmodified copy of each file now is obsolete. If you set the migfileexpiration option to zero, you can run reconciliation immediately to delete the obsolete copies from storage and create available space for your migrated files.
To manually perform all reconciliation tasks for one or more file systems, follow these steps:
If you select more than one file system, a window displays for each one. Select the window that you want to view.
After you run reconciliation, check the orphan.stubs file in the .SpaceMan directory for each file system that you reconciled to determine if any orphaned stub files were located. If the orphan.stubs file lists file names, see "Resolving Orphaned Stub Files".
To view the migration candidates list for your file system, click the file system in the Space Manager window. Click Selected->Display Migration Candidates List.
When you synchronize your file system, you update other space-management-related information. To synchronize your client and server manually, follow these steps:
After you synchronize the client and server, check the orphan.stubs file in the .SpaceMan directory for each file system that you reconciled to determine if any orphaned stub files were located. If file names are listed in the orphan.stubs file, see Resolving Orphaned Stub Files. See Appendix B, The .SpaceMan Directory for information about the .SpaceMan directory.
An orphaned stub file is a stub file for which a corresponding migrated file in storage is not located. If orphaned stub files exist in your file systems, the HSM client records information about these files in the orphan.stubs file during reconciliation. If you set the errorprog option in your dsm.sys file, a message is sent to the program that you specified with this option during automatic reconciliation.
Possible situations in which stub files might become orphaned include the following:
To resolve this problem, modify your dsm.sys file so your client node contacts the server to which the files migrated.
If files are no longer needed, an administrator can delete some or all of them from storage. In this case, the stub files are no longer valid and you can erase them.
Storage pool backup and recovery provides protection against media failures. However, if you cannot restore a migrated file from a migration storage pool, you can restore a backup version of the file if you used the backup-archive client. When you set the restoremigstate option to no in your dsm.opt file and you then restore a backup version of a migrated file, the file becomes a normal, resident file.
To check for orphaned files, specify yes on the checkfororphans option in your dsm.sys file. When orphaned files are located, their names are recorded in the .SpaceMan/orphan.stubs file. If you select yes, a full file system tree traversal is performed. In this instance, you cannot run the dsmautomig command in parallel with the dsmreconcile command.
You can use the dsmreconcile command to perform reconcile tasks rather than using the graphical user interface. If you reconcile several file systems, increase the value on the reconcileinterval option in your dsm.sys file to reduce the impact that the dsmreconcile command might have on system performance.
Use the dsmreconcile command to perform these reconciliation tasks:
Table 15. Examples Using the dsmreconcile Command
To Do This | Enter This |
---|---|
Reconcile the /home file system. | dsmreconcile /home |
Synchronize the /home file system. | dsmreconcile -f /home |
The dsmreconcile command traverses your managed file systems under the following conditions:
When you upgrade from a previous version of the HSM client, the next run of dsmreconcile on a previously managed file system forces a full tree traversal. This process occurs only once for each managed file system to update the client and server databases to the new format.
The dsmautomig command can run in parallel with dsmreconcile if it is not necessary for the dsmreconcile command to traverse your file system. The exception to this is when dsmreconcile queries the server for a list of migrated files.
For command information about dsmreconcile, see dsmreconcile. For command information about dsmautomig, see dsmautomig.
The HSM client uses the space monitor daemon, the recall daemon, and the scout daemon to manage your file systems automatically. They start when you add space management to your file systems and modify your options. The sections that follow describe each space management daemon.
The space monitor daemon monitors space usage on all file systems to which you add space management, and it starts threshold migration whenever necessary. To check space usage more frequently or less frequently, change the value on the checkthresholds option in your dsm.sys file.
To reconcile your file systems more frequently or less frequently, change the value on the reconcileinterval option in your dsm.sys file. See "Using Options" for more information about these options.
For AIX file systems only: The space monitor daemon starts automatically when you mount your file system and add space management to it. If the space monitor daemon stops running, enter the dsmmonitord command to start it.
When you change the option values that the space monitor daemon uses, the new values are not effective until you restart your system, or you stop and restart the space monitor daemon.
The recall daemon recalls migrated files from storage to your local file system. A recall daemon can recall only one file at a time; however, you can run more than one recall daemon at the same time. To set the minimum and maximum number of recall daemons that you want to run at one time, use the minrecalldaemons and maxrecalldaemons options in your dsm.sys file. The minimum number of recall daemons that you can run at the same time is one. The default is three. The maximum number of recall daemons that you can run at the same time is 99. The default is 20. See Minrecalldaemons and Maxrecalldaemons for more information about these options.
The maximum number of recalls that you can set depends on the number of concurrent recalls that normally occur on your system. If all recall daemons are busy, another file cannot be recalled until a recall daemon is available. If a frequently-used application opens several files at the same time, and that application uses all available recall daemons because all files are migrated, increase the value that you set on the maxrecalldaemons option. If a recall daemon is unable to start another process that is attempting to access a migrated file, that process cannot continue until a recall daemon is available.
The master recall daemon starts automatically when you mount your file system and add space management to it. If a recall daemon is not running, enter the dsmrecalld command to start one.
When you change the option values that the recall daemons use, the new values are not effective until you restart your system, or you stop and restart the master recall daemon.
The scout daemon automatically searches for candidates on each file system for which space management is active. To specify how regularly a search for candidates will start on a file system, modify the setting on the candidatesinterval option in your dsm.sys file. If you modify the setting to the maximum value of 9999, the scout daemon does not search in regular cycles for migration candidates. It searches for migration candidates only on requests from the automigration process.
To stop the space monitor, master recall or subordinate recall daemons, or scout daemon, follow these steps: