Dynamic Storage Technology supports shadow volumes created with OES Storage Services volumes. NSS volume attributes, features, and actions can behave differently while the volume is in a shadow relationship. Consider the guidelines and caveats in this section when planning your shadow volume solution.
Ensure that 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 9-1 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 Storage Services File System (NSS) Administration Guide for Linux.
Table 9-1 DST Support for NSS Volume Attributes
|
NSS Volume Attribute |
Supported |
Caveats |
|---|---|---|
|
AD Enabled |
Yes |
For AD users to access an NSS32 or NSS64 volume,
For more information, see Volume AD-enabling and Understanding Volume Properties in the Storage Services File System (NSS) Administration Guide for Linux. |
|
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 9.7, Using NSS Quotas on DST Shadow Volume Pairs. |
|
File-level Snapshot |
Yes |
No known issues. |
|
Flush Files Immediately |
Yes |
No known issues. |
|
Lookup Namespace |
Yes |
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. The Salvage attribute is set separately on each of the NSS volumes in the pair. Because a file can exist on either the primary volume or the secondary volume, a single instance of a deleted file is saved to the volume where it resides when it is deleted. A salvaged file is restored to the volume where it resided when it was deleted. The primary volume and the secondary volume each have an instance of a folder in their file trees. When you delete a folder, both instances are deleted, and each folder’s content is also deleted. Each of the deleted folder instances contain different deleted files. DST does not present a merged view of the deleted folders and files. Duplicate deleted folders are presented when you use the Salvage (undelete) and Purge options for folders. In a Salvage list or Purge list, the folder instance that resided on the primary volume when the folder was deleted has a valid Deleter ID. The folder instance that resided on the secondary volume reports that the Deleter ID is [Supervisor]. You must salvage both deleted folders to access the deleted files in each. In NFARM utility, when you use salvage or purge options, the salvage or purge list displays only one instance of the deleted folder with the correct Deleter ID. You can salvage the deleted folder to their original location and access the deleted files. The deleted files are restored at their appropriate primary and secondary volumes. |
|
User Space Quotas |
Yes |
Set up the user space quotas separately on each of the volumes. For more information, see Section 9.7, Using NSS Quotas on DST Shadow Volume Pairs. |
|
User-level Transaction Model |
No |
NSS does not support the NetWare Transaction Tracking System for NSS volumes on Linux. |
Table 9-2 describes caveats for using the NSS volume features and actions when working with DST shadow volumes.
Table 9-2 Caveats for NSS Features and Actions
|
NSS Feature |
Supported |
Caveats |
|---|---|---|
|
Novell Distributed File Services |
Yes |
Some limitations apply. For information, see Section 9.10, Using Novell Distributed File Services with DST Shadow Volume Pairs. |
|
Encryption |
Yes |
Using encrypted NSS volumes is supported for DST shadow volume pairs. For information, see Section 9.6, Using NSS Encrypted Volumes in a DST Shadow Volume Pair. |
|
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 9.9, Using OES Cluster Services with DST Shadow Volume Pairs. |
|
Volume quotas |
Yes |
Set the volume quotas separately for each volume. For more information, see Section 9.7, Using NSS Quotas on DST Shadow Volume Pairs. |