Dynamic Storage Technology supports shadow volumes created with Novell Storage Services volumes. Consider the guidelines and caveats in this section when planning your shadow volume solution.
Make sure you enable the same NSS volume attributes on both volumes in the shadow relationship to ensure a consistent user experience. For example, if Salvage is enabled for the primary volume but not for the secondary volume, files that are deleted when they reside on the secondary volume are purged immediately, and are not available for salvage.
Table 5-2 describes which NSS volume attributes are supported for use with Dynamic Storage Technology, and any caveats to consider when using them. For information about the volume attributes, see Volume Attributes
in the OES 2 SP3: NSS File System Administration Guide for Linux.
Table 5-2 DST Support for NSS Volume Attributes
NSS Volume Attribute |
Supported |
Caveats |
---|---|---|
Allow mount point to be renamed |
No |
DST does not track the renaming of NSS volumes or their mount points. Before you rename or modify the mount point for an NSS volume, you must remove the shadow volume definition. Afterwards, you can re-create the shadow volume. |
Backup |
Yes |
The Linux file system sees both volumes, so you back up each volume separately. |
Compression |
Yes |
You can set compression on one or both volumes. Compressed files are uncompressed when they are moved from the primary volume to secondary volume, and vice versa. In order for the move to occur, there must be sufficient space on the source volume to allow both the uncompressed and compressed copies of the file to coexist until the move is completed. There must also be sufficient space on the destination volume for the uncompressed file to be stored. The file is re-compressed according to the compression schedule and settings in the destination volume. |
Data Shredding |
Yes |
For security compliance reasons, you should set this attribute on both volumes if you use it. |
Directory Quotas |
Yes |
Set a directory quota for a directory only on the primary volume. For more information, see Section 5.7, Using NSS Quotas on DST Shadow Volumes. |
File-level Snapshot |
Yes |
No known issues. |
Flush Files Immediately |
Yes |
No known issues. |
Lookup Namespace |
Yes |
In OES 2 SP1 and later, the default Lookup Namespace for NSS on Linux is Long, which treats file names as case insensitive. In prior versions, the default name space is UNIX. Using the Long name space helps improve performance because NetWare and Windows treat file names as case insensitive. This is especially important when files are accessed through the SMB/CIFS protocol. |
Migration (to near-line HSM storage) |
No |
DST should not be used in combination with HSM storage solutions. |
Modified File List (Use Event File List APIs instead.) |
No |
By default, modified files are moved back to the primary location. If you disable the Shift Modified Files parameter, modified files might also be located on the secondary location. Modified File List is rarely used. It has been replaced by the Event File List APIs that provide more information than the Modified File List. For information, see |
Salvage |
Yes |
Deleted files on a NSS volume that are salvageable remain salvageable after that volume is used in a shadow volume pair. Duplicate deleted folders might be presented when using Salvage (undelete) and Purge options for folders. You must restore the folders in order to see which one contains the deleted files (on the primary volume), and which is empty (on the secondary volume). NetStorage does not see the deleted files that are available for salvage on the secondary volume. |
User Space Quotas |
Yes |
Set up the user space quotas separately on each of the volumes. For more information, see Section 5.7, Using NSS Quotas on DST Shadow Volumes. |
User-level Transaction Model |
No |
NSS does not support the NetWare Transaction Tracking System for NSS volumes on Linux. |
Table 5-3 describes caveats for using the NSS volume features and actions when working with DST shadow volumes.
Table 5-3 Caveats for NSS Features and Actions
NSS Feature |
Supported |
Caveats |
---|---|---|
Novell Archive and Version Services |
Yes |
File versions can be archived only for files located on the primary volume of the DST shadow volume. You cannot set up archive jobs for the secondary volume. |
Novell Distributed File Services |
Yes |
Some limitations apply. For information, see Section 5.9, Using Novell Distributed File Services with DST Shadow Volumes. |
Encryption |
Yes |
Beginning in OES 2 SP3, using encrypted NSS volumes is supported for DST shadow volume pairs. For information, see Section 5.6, Using NSS Encrypted Volumes in a DST Shadow Volume. |
Hard links |
No |
DST does not support hard links on NSS volumes used in a shadow volume. if a file is a hard link, and the hard-linked file is moved between the primary and the secondary area, the move is really a copy and has the effect of breaking the hard link and creating an additional version of the file that is not linked to the other ones. |
Media format for enhanced hard links |
Yes |
The media format that supports enhanced hard links is supported, but the hard links themselves are not. |
Multiple Server Activation Prevention |
Yes |
Each pool enforces this separately. |
Pool low-space warnings and watermarks |
Yes |
You must set the pool-level watermarks for low-space warnings separately for the primary pool and the secondary pool. IMPORTANT:NSS does not have a volume-level low-space-warning feature. However, you can take advantage of the NCP Server global parameters for managing low-space warnings for NCP volumes on NSS, Ext3, and Reiser file systems. For information, see |
Pool snapshots |
Yes |
Take pool snapshots separately for the primary and secondary pools. IMPORTANT:For NSS on Linux, pool snapshots are not supported for clustered pools. If the primary volume is configured to contain the most frequently used data, pool snapshots of the primary pool have a higher percentage of changed data than does the secondary pool. |
Renaming a volume’s mount point |
No |
Renaming a volume’s mount point breaks the shadow volume. If you need to rename a volume’s mount point, remove the shadow, rename the volume’s mount point, then create the shadow volume again. |
Renaming a volume |
No |
Renaming a volume breaks the shadow volume. If you need to rename a volume, remove the shadow, rename the volume, then create the shadow volume again. |
Resizing (growing) a pool |
Yes |
No known issues. |
Sharing a pool and its volumes in a cluster |
Yes |
When using NSS volumes in shared pools, you must manage both pools’ resources in the primary pool resource load and unload scripts. For information, see Section 5.8, Using DST Shadow Volumes with Novell Cluster Services. |
Volume quotas |
Yes |
Set the volume quotas separately for each volume. For more information, see Section 5.7, Using NSS Quotas on DST Shadow Volumes. |