Migration via external interposition
Shadow filesystem semantics during migration
Snapshots of shadow filesystems
Replicating shadow filesystems
Migration of local filesystems
Testing potential shadow migration
Migrating data from an active NFS server
Filesystem and project settings
Protocol access to mountpoints
Non-blocking mandatory locking
Create a project level snapshot
Create a share/LUN level snapshot
Rolling back to a Snapshot (BUI)
Rolling back to a Snapshot (CLI)
Setting the Scheduled Snapshot Label (CLI)
Remote Replication Introduction
Project-level vs. Share-level Replication
Modes: Scheduled or Continuous
Including Intermediate Snapshots
Cloning a Package or Individual Shares
Exporting Replicated Filesystems
Reversing the Direction of Replication
Destroying a Replication Package
Reversing Replication - Establish Replication
Reversing Replication - Simulate Recovery from a Disaster
Reversing Replication - Resume Replication from Production System
Cloning a Received Replication Project
Snapshots and Data Consistency
Replicating iSCSI Configuration
In addition to the standard built in properties, you can configure any number of additional properties that are available on all shares and projects. These properties are given basic types for validation purposes, and are inherited like most other standard properties. The values are never consumed by the software in any way, and exist solely for end-user consumption. The property schema is global to the system, across all pools, and is synchronized between cluster peers.
To define custom properties, access the "Shares -> Schema" navigation item. The current schema is displayed as a list, and entries can be added or removed as needed. Each property has the following fields:
|
The valid types for properties are the following
|
Once defined, the properties are available under the general properties tab, using the description provided in the property table. Properties are identified by their CLI name, so renaming a property will have the effect of removing all existing settings on the system. A property that is removed and later renamed back to the original name will still refer to the previously set values. Changing the types of properties, while supported, may have undefined results on existing properties on the system. Existing properties will retain their current settings, even if they would be invalid given the new property type.
The schema context can be found at "shares -> schema"
carp:> shares schema carp:shares schema> show Properties: NAME TYPE DESCRIPTION owner EmailAddress Owner Contact
Each property is a child of the schema context, using the name of the property as the token. To create a property, use the create command:
carp:shares schema> create department
carp:shares schema department (uncommitted)> get
type = String
description = department
carp:shares schema department (uncommitted)> set description="Department Code"
description = Department Code (uncommitted)
carp:shares schema department (uncommitted)> commit
carp:shares schema>
Within the context of a particular property, fields can be set using the standard CLI commands:
carp:shares schema> select owner
carp:shares schema owner> get
type = EmailAddress
description = Owner Contact
carp:shares schema owner> set description="Owner Contact Email"'
description = Owner Contact Email (uncommitted)
carp:shares schema owner> commit
Once custom properties have been defined, they can be accessed like any other property under the name "custom:<property>":
carp:shares default> get
...
custom:department = 123-45-6789
custom:owner =
...
carp:shares default> set custom:owner=bob@corp
custom:owner = bob@corp (uncommitted)
carp:shares default> commit
Create a property to track contact information.