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.