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 automatically created on the primary volume.
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.
If you rename a folder through the merged view, the name is changed on the instance of the folder in the primary location and the secondary location.
Always use the merged view when renaming or modifying files. Do not rename or modify files or directories by directly accessing them on the secondary location.
If you rename a folder by directly accessing the folder on the secondary location, the instance of the folder on the primary location is not renamed or deleted. Instead, an instance is created on the primary location for the newly renamed folder. The renamed folder contains the files that were stored in it when it was renamed. The files appear to have disappeared from the original instance of the folder.
When the NCP protocol is used in conjunction with the NSS file system, all native NCP functionality (security, rights, trustees, salvage, directory quotas, and so on) is preserved in a DST environment. No functionality is lost, and no management patterns are changed.
When you use Novell 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 Novell iManager 2.7, NSSMU, and Novell 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.