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 Cancelling Updates

Managing Replication Packages

BUI

CLI

Cancelling 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

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

General

General Share Properties

This section of the BUI controls overall settings for the share that are independent of any particular protocol and are not related to access control or snapshots. While the CLI groups all properties in a single list, this section describes the behavior of the properties in both contexts.

For information on how these properties map to the CLI, see the Shares CLI section.

Space Usage

Space within a storage pool is shared between all shares. Filesystems can grow or shrink dynamically as needed, though it is also possible to enforce space restrictions on a per-share basis. Quotas and reservations can be enforced on a per-filesystem basis. Quotas can also be enforced per-user and per-group. For more information on manging space usage for filesystems, including quotas and reservations, see the Space Management section.

Volume size

The logical size of the LUN as exported over iSCSI. This property is only valid for LUNs.

This property controls the size of the LUN. By default, LUNs reserve enough space to completely fill the volume. See the Thin provisioned property for more information. Changing the size of a LUN while actively exported to clients may yield undefined results. It may require clients to reconnect and/or cause data corruption on the filesystem on top of the LUN. Check best practices for your particular iSCSI client before attempting this operation.

Thin provisioned

Controls whether space is reserved for the volume. This property is only valid for LUNs.

By default, a LUN reserves exactly enough space to completely fill the volume. This ensures that clients will not get out-of-space errors at inopportune times. This property allows the volume size to exceed the amount of available space. When set, the LUN will consume only the space that has been written to the LUN. While this allows for thin provisioning of LUNs, most filesystems do not expect to get "out of space" from underlying devices, and if the share runs out of space, it may cause instability and/or data corruption on clients.

When not set, the volume size behaves like a reservation excluding snapshots. It therefore has the same pathologies, including failure to take snapshots if the snapshot could theoretically diverge to the point of exceeding the amount of available space. For more information, see the Reservation property.

Properties

These are standard properties that can either be inherited from the project or explicitly set on the share. The BUI only allows the properties to be inherited all at once, while the CLI allows for individual properties to be inherited.

Mountpoint

The location where the filesystem is mounted. This property is only valid for filesystems.

The following restrictions apply to the mountpoint property:

When inheriting the mountpoint property, the current dataset name is appended to the project's mountpoint setting, joined with a slash ('/'). For example, if the "home" project has the mountpoint setting /export/home, then "home/bob" would inherit the mountpoint /export/home/bob.

SMB shares are exported via their resource name, and the mountpoint is not visible over the protocol. However, even SMB-only shares must have a valid unique mountpoint on the appliance.

Mountpoints can be nested underneath other shares, though this has some limitations. For more information, see the filesystem namespace section.

Read only

Controls whether the filesystem contents are read only. This property is only valid for filesystems.

The contents of a read only filesystem cannot be modified, regardless of any protocol settings. This setting does not affect the ability to rename, destroy, or change properties of the filesystem. In addition, when a filesystem is read only, Access control properties cannot be altered, because they require modifying the attributes of the root directory of the filesystem.

Update access time on read

Controls whether the access time for files is updated on read. This property is only valid for filesystems.

POSIX standards require that the access time for a file properly reflect the last time it was read. This requires issuing writes to the underlying filesystem even for a mostly read only workload. For working sets consisting primarily of reads over a large number of files, turning off this property may yield performance improvements at the expense of standards conformance. These updates happen asynchronously and are grouped together, so its effect should not be visible except under heavy load.

Non-blocking mandatory locking

Controls whether SMB locking semantics are enforced over POSIX semantics. This property is only valid for filesystems.

By default, filesystems implement file behavior according to POSIX standards. These standards are fundamentally incompatible with the behavior required by the SMB protocol. For shares where the primary protocol is SMB, this option should always be enabled. Changing this property requires all clients to be disconnected and reconnect.

Data deduplication

Controls whether duplicate copies of data are eliminated.

Deduplication is synchronous, pool-wide, block-based, and can be enabled on a per project or share basis. Enable it by selecting the Data Deduplication checkbox on the general properties screen for projects or shares. The deduplication ratio will appear in the usage area of the Status Dashboard.

Data written with deduplication enabled is entered into the deduplication table indexed by the data checksum. Deduplication forces the use of the cryptographically strong SHA-256 checksum. Subsequent writes will identify duplicate data and retain only the existing copy on disk. Deduplication can only happen between blocks of the same size, data written with the same record size. As always, for best results set the record size to that of the application using the data; for streaming workloads use a large record size.

If your data doesn't contain any duplicates, enabling Data Deduplication will add overhead (a more CPU-intensive checksum and on-disk deduplication table entries) without providing any benefit. If your data does contain duplicates, enabling Data Deduplication will both save space by storing only one copy of a given block regardless of how many times it occurs. Deduplication necessarily will impact performance in that the checksum is more expensive to compute and the metadata of the deduplication table must be accessed and maintained.

Note that deduplication has no effect on the calculated size of a share, but does affect the amount of space used for the pool. For example, if two shares contain the same 1GB file, each will appear to be 1GB in size, but the total for the pool will be just 1GB and the deduplication ratio will be reported as 2x.

Performance Warning: by its nature, deduplication requires modifying the deduplication table when a block is written to or freed. If the deduplication table cannot fit in DRAM, writes and frees may induce significant random read activity where there was previously none. As a result, the performance impact of enabling deduplication can be severe. Moreover, for some cases -- in particular, share or snapshot deletion -- the performance degradation from enabling deduplication may be felt pool-wide. In general, it is not advised to enable deduplication unless it is known that a share has a very high rate of duplicated data, and that that duplicated data plus the table to reference it can comfortably reside in DRAM. To determine if performance has been adversely affected by deduplication, enable advanced analytics and then use analytics to measure "ZFS DMU operations broken down by DMU object type" and check for a higher rate of sustained DDT operations (Data Duplication Table operations) as compared to ZFS operations. If this is happening, more I/O is for serving the deduplication table rather than file I/O.

Data compression

Controls whether data is compressed before being written to disk.

Shares can optionally compress data before writing to the storage pool. This allows for much greater storage utilization at the expense of increased CPU utilization. By default, no compression is done. If the compression does not yield a minimum space savings, it is not committed to disk to avoid unnecessary decompression when reading back the data. Before choosing a compression algorithm, it is recommended that you perform any necessary performance tests and measure the achieved compression ratio.

BUI value
CLI value
Description
Off
off
No compression is done
LZJB (Fastest)
lzjb
A simple run-length encoding that only works for sufficiently simple inputs, but doesn't consume much CPU.
GZIP-2 (Fast)
gzip-2
A lightweight version of the gzip compression algorithm.
GZIP (Default)
gzip
The standard gzip compression algorithm.
GZIP-9 (Best Compression)
gzip-9
Highest achievable compression using gzip. This consumes a significant amount of CPU and can often yield only marginal gains.
Checksum

Controls the checksum used for data blocks.

On the appliance, all data is checksummed on disk, and in such a way to avoid traditional pitfalls (phantom reads and write in particular). This allows the system to detect invalid data returned from the devices. The default checksum (fletcher4) is sufficient for normal operation, but paranoid users can increase

the checksum strength at the expense of additional CPU load. Metadata is always checksummed using the same algorithm, so this only affects user data (files or LUN blocks).

BUI value
CLI value
Description
Fletcher 2 (Legacy)
fletcher2
16-bit fletcher checksum
Fletcher 4 (Standard)
fletcher4
32-bit fletcher checksum
SHA-256 (Extra Strong)
sha256
SHA-256 checksum
Cache device usage

Controls whether cache devices are used for the share.

By default, all datasets make use of any cache devices on the system. Cache devices are configured as part of the storage pool and provide an extra layer of caching for faster tiered access. For more information on cache devices, see the storage configuration section. This property is independent of whether there are any cache devices currently configured in the storage pool. For example, it is possible to have this property set to "all" even if there are no cache devices present. If any such devices are added in the future, the share will automatically take advantage of the additional performance. This property does not affect use of the primary (DRAM) cache.

BUI value
CLI value
Description
All data and metadata
all
All normal file or LUN data is cached, as well as any metadata.
Metadata only
metadata
Only metadata is kept on cache devices. This allows for rapid traversal of directory structures, but retrieving file contents may require reading from the data devices.
Do not use cache devices
none
No data in this share is cached on the cache device. Data is only cached in the primary cache or stored on data devices.
Synchronous write bias

This setting controls the behavior when servicing synchronous writes. By default, the system optimizes synchronous writes for latency, which leverages the log devices to provide fast response times. In a system with multiple disjoint filesystems, this can cause contention on the log devices that can increase latency across all consumers. Even with multiple filesystems requesting synchronous semantics, it may be the case that some filesystems are more latency-sensitive than others. A common case is a database that has a separate log. The log is extremely latency sensitive, and while the database itself also requires synchronous semantics, it is heavier bandwidth and not latency sensitive. In this environment, setting this property to 'throughput' on the main database while leaving the log filesystem as 'latency' can result in significant performance improvements. Note that this setting will change behavior even when no log devices are present, though the effects may be less dramatic.

BUI value
CLI value
Description
Latency
latency
Synchronous writes are optimized for latency, leveraging the dedicated log device(s), if any.
Throughput
throughput
Synchronous writes are optimized for throughput. Data is written to the primary data disks instead of the log device(s), and the writes are performed in a way that optimizes for total bandwidth of the system.
Database record size

Controls the block size used by the filesystem. This property is only valid for filesystems.

By default, filesystems will use a block size just large enough to hold the file, or 128K for large files. This means that any file over 128K in size will be using 128K blocks. If an application then writes to the file in small chunks, it will necessitate reading and writing out an entire 128K block, even if the amount of data being written is comparatively small.

Shares that host small random access workloads (i.e. databases) should tune this property to be approximately equal to the record size used by the database. In the absence of a precise number, 8K is typically a good choice for most database workloads. The property can be set to any power of 2 from 512 to 128K.

Additional replication

Controls number of copies stored of each block, above and beyond any redundancy of the storage pool.

Metadata is always stored with multiple copies, but this property allows the same behavior to be applied to data blocks. The storage pool attempts to store these extra blocks on different devices, but it is not guaranteed. In addition, a storage pool cannot be imported if a complete logical device (RAID stripe, mirrored pair, etc) is lost. This property is not a replacement for proper replication in the storage pool, but can be reassuring for paranoid administrators.

BUI value
CLI value
Description
Normal (Single Copy)
1
Default behavior. Store a single copy of data blocks.
Two Copies
2
Store two copies of every data block.
Three Copies
3
Store three copies of every data block.
Virus scan

Controls whether this filesystem is scanned for viruses. This property is only valid for filesystems.

This property setting is independent of the state of the virus scan service. Even if the Virus Scan service is enabled, filesystem scanning must be explicitly enabled using this property. Similarly, virus scanning can be enabled for a particular share even if the service itself is off. For more information about configuration virus scanning, see the Virus Scan section.

Prevent destruction

When set, the share or project cannot be destroyed. This includes destroying a share through dependent clones, destroying a share within a project, or destroying a replication package. However, it does not affect shares destroyed through replication updates. If a share is destroyed on an appliance that is the source for replication, the corresponding share on the target will be destroyed, even if this property is set.

To destroy the share, the property must first be explicitly turned off as a separate step. This property is off by default.

Restrict ownership change

By default, ownership of files cannot be changed except by a root user (on a suitable client with a root-enabled export). This property can be

turned off on a per-filesystem or per-project basis by turning off this property. When off, file ownership can be changed by the owner of the file or directory, effectively allowing users to "give away" their own files. When ownership is changed, any setuid or setgid bits are stripped, preventing users from escalating privileges through this operation.

Custom Properties

Custom properties can be added as needed to attach user-defined tags to projects and shares. For more information, see the schema section.