JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Sun ZFS Storage 7000 System Administration Guide
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Status

3.  Configuration

4.  Services

5.  Shares

Shares

Introduction

Concepts

Storage Pools

Projects

Shares

Properties

Snapshots

Clones

Shadow Migration

Shadow Data Migration

Traditional Data Migration

Migration via synchronization

Migration via external interposition

Shadow Migration

Shadow migration behavior

Restrictions on shadow source

Shadow filesystem semantics during migration

Identity and ACL migration

Shadow Migration Management

Creating a shadow filesystem

Managing background migration

Handling errors

Monitoring progress

Canceling migration

Snapshots of shadow filesystems

Backing up shadow filesystems

Replicating shadow filesystems

Shadow migration analytics

Shadow migration requests

Shadow migration bytes

Shadow migration operations

Migration of local filesystems

Tasks

Testing potential shadow migration

Migrating data from an active NFS server

Space Management

Introduction

Terms

Space Management Terms

Physical Data

Logical Data

Referenced Data

Snapshot Data

Quota

Reservation

Understanding snapshots

Filesystem and project settings

Data quotas

Data reservations

User and group settings

Viewing current usage

BUI

CLI

User or group quotas

BUI

CLI

Identity management

Filesystem Namespace

Filesystem namespace

Nested mountpoints

Protocol access to mountpoints

NFSv2 / NFSv3

NFSv4

SMB

FTP / FTPS / SFTP

HTTP / HTTPS

Shares

BUI

List of Shares

Editing a Share

Usage Statistics

Available space

Referenced data

Snapshot data

Unused Reservation

Total space

Static Properties

Compression ratio

Case sensitivity

Reject non UTF-8

Normalization

Volume block size

Origin

Data Migration Source

Project Panel

Creating Shares

CLI

Navigation

Share Operations

Properties

General

General Share Properties

Space Usage

Volume size

Thin provisioned

Properties

Mountpoint

Read only

Update access time on read

Non-blocking mandatory locking

Data deduplication

Data compression

Checksum

Cache device usage

Synchronous write bias

Database record size

Additional replication

Virus scan

Prevent destruction

Restrict ownership change

Custom Properties

Protocols

Shares Protocols

NFS

CLI Considerations

Security Modes

Character set encodings

SMB

SCSI

HTTP

FTP

SFTP

Access

Access Control

Root Directory Access

User

Group

Permissions

ACL Behavior

ACL behavior on mode change

ACL inheritance behavior

Root Directory ACL

Snapshots

Introduction

Snapshot Properties

.zfs/snapshot visible

BUI

Listing Snapshots

Taking Snapshots

Renaming a Snapshot

Destroying a Snapshot

Rolling back to a Snapshot

Cloning a Snapshot

Scheduled Snapshots

CLI

Listing Snapshots

Taking Snapshots

Renaming a Snapshot

Destroying a Snapshot

Rolling back to a Snapshot

Cloning a Snapshot

Scheduled Snapshots

Projects

BUI

List of Projects

Editing a Project

Usage Statistics

Available space

Referenced data

Snapshot data

Unused Reservation

Unused Reservation of shares

Total space

Static Properties

Compression ratio

Creating Projects

CLI

Navigation

Project Operations

Selecting a pool in a cluster

Properties

General

General Project Properties

Space Usage

Quota

Reservation

Inherited Properties

Custom Properties

Filesystem Creation Defaults

LUN Creation Defaults

Protocols

Project Protocols

NFS

SMB

iSCSI

HTTP

FTP

Access

Access Control

Inherited ACL Behavior

Snapshots

Introduction

Snapshot Properites

.zfs/snapshot visible

BUI

CLI

Replication

Remote Replication Introduction

Concepts

Terminology

Targets

Actions and Packages

Storage Pools

Project-level vs Share-level Replication

Configuring Replication

Creating and Editing Targets

Creating and Editing Actions

Modes: Manual, Scheduled, or Continuous

Including Intermediate Snapshots

Sending and Canceling Updates

Managing Replication Packages

BUI

CLI

Canceling Replication Updates

Disabling a Package

Cloning a Package or Individual Shares

Exporting Replicated Filesystems

Severing Replication

Reversing the Direction of Replication

Destroying a Replication Package

Examples

Reversing Replication

Remote Replication Details

Authorizations

Alerts

Replication and Clustering

Snapshots and Data Consistency

Snapshot Management

Replicating iSCSI Configuration

Replicating Clones

Observing Replication

Replication Failures

Upgrading From 2009.Q3 and Earlier

Schema

Customized Share Properties

BUI

CLI

Tasks

Create a property to track contact info

6.  Analytics

7.  Application Integration

Glossary

Index

Concepts

Storage Pools

The appliance is based on the ZFS filesystem. ZFS groups underlying storage devices into pools, and filesystems and LUNs allocate from this storage as needed. Before creating filesystems or LUNs, you must first configure storage on the appliance. Once a storage pool is configured, there is no need to statically size filesystems, though this behavior can be achieved by using quotas and reservations.

While multiple storage pools are supported, this type of configuration is generally discouraged because it provides significant drawbacks as described in the storage configuration section. Multiple pools should only be used where the performance or reliability characteristics of two different profiles are drastically different, such as a mirrored pool for databases and a RAID-Z pool for streaming workloads.

When multiple pools are active on a single host, the BUI will display a drop-down list in the menu bar that can be used to switch between pools. In the CLI, the name of the current pool will be displayed in parenthesis, and can be changed by setting the 'pool' property. If there is only a single pool configured, then these controls will be hidden. When multiple pools are selected, the default pool chosen by the UI is arbitrary, so any scripted operation should be sure to set the pool name explicitly before manipulating any shares.

Projects

All filesystems and LUNs are grouped into projects. A project defines a common administrative control point for managing shares. All shares within a project can share common settings, and quotas can be enforced at the project level in addition to the share level. Projects can also be used solely for grouping logically related shares together, so their common attributes (such as accumulated space) can be accessed from a single point.

By default, the appliance creates a single default project when a storage pool is first configured. It is possible to create all shares within this default project, although for reasonably sized environments creating additional projects is strongly recommended, if only for organizational purposes.

Shares

Shares are filesystems and LUNs that are exported over supported data protocols to clients of the appliance. Filesystems export a file-based hierarchy and can be accessed over SMB, NFS, HTTP/WebDav, and FTP. LUNs export block-based volumes and can be accessed over iSCSI or Fibre Channel. The project/share tuple is a unique identifier for a share within a pool. Multiple projects can contain shares with the same name, but a single project cannot contain shares with the same name. A single project can contain both filesystems and LUNs, and they share the same namespace.

Properties

All projects and shares have a number of associated properties. These properties fall into the following groups:

Property Type
Description
Inherited
This is the most common type of property, and represents most of the configurable project and share properties. Shares that are part of a project can either have local settings for properties, or they can inherit their settings from the parent project. By default, shares inherit all properties from the project. If a property is changed on a project, all shares that inherit that property are updated to reflect the new value. When inherited, all properties have the same value as the parent project, with the exception of the mountpoint and SMB properties. When inherited, these properties concatenate the project setting with their own share name.
Read-only
These properties represent statistics about the project and share and cannot be changed. The most common properties of this type are space usage statistics.
Space Management
These properties (quota and reservation) apply to both shares and projects, but are not inherited. A project with a quota of 100G will be enforced across all shares, but each individual share will have no quota unless explicitly set.
Create time
These properties can be specified at filesystem or LUN creation time, but cannot be changed once the share has been created. These properties control the on-disk data structures, and include internationalization settings, case sensitivity, and volume block size.
Project default
These properties are set on a project, but do not affect the project itself. They are used to populate the initial settings when creating a filesystem or LUN, and can be useful when shares have a common set of non-inheritable properties. Changing these properties do not affect existing shares, and the properties can be changed before or after creating the share.
Filesystem local
These properties apply only to filesystems, and are convenience properties for managing the root directory of the filesystem. They cannot be set on projects. These access control properties can also be set by in-band protocol operations.
LUN local
These properties apply only to LUNs and are not inherited. They cannot be set on projects.
Custom
These are user defined properties. For more information, see the schema section.

Snapshots

A snapshot is a point-in-time copy of a filesystem or LUN. Snapshots can be created manually or by setting up an automatic schedule. Snapshots initially consume no additional space, but as the active share changes, previously unreferenced blocks will be kept as part of the last snapshot. Over time, the last snapshot will take up additional space, with a maximum equivalent to the size of the filesystem at the time the snapshot was taken.

Filesystem snapshots can be accessed over the standard protocols in the .zfs/snapshot snapshot at the root of the filesystem. This directory is hidden by default, and can only be accessed by explicitly changing to the .zfs directory. This behavior can be changed in the Snapshot view, but may cause backup software to backup snapshots in addition to live data. LUN Snapshots cannot be accessed directly, though they can be used as a rollback target or as the source of a clone. Project snapshots are the equivalent of snapshotting all shares within the project, and snapshots are identified by name. If a share snapshot that is part of a larger project snapshot is renamed, it will no longer be considered part of the same snapshot, and if any snapshot is renamed to have the same name as a snapshot in the parent project, it will be treated as part of the project snapshot.

Shares support the ability to rollback to previous snapshots. When a rollback occurs, any newer snapshots (and clones of newer snapshots) will be destroyed, and the active data will be reverted to the state when the snapshot was taken. Snapshots only include data, not properties, so any property settings changed since the snapshot was taken will remain.

Clones

LICENSE NOTICE: Remote Replication and Cloning may be evaluated free of charge, but each feature requires that an independent license be purchased separately for use in production. After the evaluation period, these features must either be licensed or deactivated. Oracle reserves the right to audit for licensing compliance at any time. For details, refer to the "Oracle Software License Agreement ("SLA") and Entitlement for Hardware Systems with Integrated Software Options."

A clone is a writable copy of a share snapshot, and is treated as an independent share for administrative purposes. Like snapshots, a clone will initially take up no extra space, but as new data is written to the clone, the space required for the new changes will be associated with the clone. Clones of projects are not supported. Because space is shared between snapshots and clones, and a snapshot can have multiple clones, a snapshot cannot be destroyed without also destroying any active clones.