Consider the guidelines in this section when working with DST shadow volumes.
DST supports the following number of DST shadow volume pairs per DST server:
Physical server: 32
Virtual server: 16
IMPORTANT:This constraint is imposed because of a known defect in FUSE (File System in Userspace).
DST shadow volumes are intended for use with data volumes that contain unstructured data. Consider the following guidelines for choosing which volumes to use with DST:
Do not put system files and application files on DST shadow volumes.
Do not create a DST shadow volume for the _ADMIN volume.
If the volume contains database files. rebuild situations might occur because of the additional latency related to the DST handling, or if the secondary storage area becomes unavailable for any reason.
Policies should exclude directories that contain databases such as those for Novell GroupWise and MySQL. You can alternatively create policies in such a way that they do not affect database files.
New files are created via the merged view and are saved on the primary volume.
New folders are created via merged view and are saved on the primary volume and secondary volume immediately.
While a file is moved from one area to the other, the file is locked so that clients cannot access it during relocation.
A policy cannot move a file between the areas if the file is open.
When DST enforces policies or moves files, the relocation request fails if a user has the file open; only files that are not in use can be moved.
Always use the merged view when you perform actions on a file, such as open, close, create, delete, rename, modify, set trustees, set trustee rights, or set inherited rights.
Do not perform these actions by directly accessing files on the secondary location, except when the root user backs up files, restores files, or resolves instances of duplicate files.
Always use the merged view when you perform actions on a folder, such as open, close, create, delete, rename, modify, set trustees, set trustee rights, or set inherited rights.
Do not perform these actions by directly accessing folders on the secondary location, except when the root user backs up files or restores files.
When you rename a folder via the merged view, its name is changed on the instance of the folder in the primary location and the secondary location.
If you rename a folder by directly accessing it on the secondary location, the instance of the folder on the primary location is not renamed or deleted. The renamed folder contains the files that were stored in it when it was renamed. The files appear to have disappeared from the primary instance of the folder.
If you delete a folder by directly accessing it on the secondary location, the instance of the folder on the primary location is not deleted.
If you define a DST shadow volume pair with an existing volume as secondary and a new volume as primary, the directory structure is replicated gradually to the primary volume as files are used or moved there with a policy. Empty folders are not automatically replicated on the new primary volume. To ensure that the entire existing directory structure (including empty directories) is replicated on the primary volume, an administrator can enumerate the directory from an NCP client that is mapped to the merged view.
When the NCP protocol is used in conjunction with the NSS file system, all native NCP functionality (security, rights, trustees) is preserved in a DST environment. No functionality is lost, and no management patterns are changed.
When you use OES CIFS or Novell Samba, all native CIFS functionality for security, rights, and so on is preserved in a DST environment. The conversion of CIFS ACLs (access control lists) to NSS ACLs based on the POSIX definitions is based on code resident in Samba and is not supported for modification by Novell.
IMPORTANT:The CIFS support of ACLs is offered as-is, and is not modified to take advantage of the expanded management features of NSS file systems.
You can continue using existing file management utilities that currently execute successfully against the designated file systems. DST is transparent to this operation. All file management operations currently available to NSS users through iManager, NSSMU, and OES Remote Manager for Linux function transparently for shadow volumes. File operations and the location of the file are transparent to the NCP and CIFS clients.