9.4 Using NSS Volumes in DST Shadow Volume Pairs

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.

9.4.1 DST Support for NSS Volume Attributes

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 OES 2018 SP3: NSS File System 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, the volume must be part of a pool that is AD media upgraded the volume must be AD Enabled For more information, see Volume AD-enabling and Understanding Volume Properties in the OES 2018 SP3: NSS File System 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 Using the Event File List to Refine the Backup in the OES 2018 SP3: NSS File System Administration Guide for Linux.
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. NetStorage does not see the deleted files that are available for salvage on the secondary volume. 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.

9.4.2 DST Support for NSS Features and Actions

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 NCP Volumes Low-Space Warning in the OES 2018 SP3: NCP Server for Linux Administration Guide.
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.