"Oracle Solaris 11.3 ZFS文件系统管理手册"

需积分: 5 143 浏览量更新于2024-01-28 收藏 1.24MB PDF 举报

"Oracle Solaris 11.3 Managing ZFS File Systems-290" is a comprehensive guide to managing ZFS file systems in Oracle Solaris 11.3. This publication, with the part number E54801, is copyrighted by Oracle and its affiliates and is protected by intellectual property laws. It provides detailed information on managing ZFS file systems and is intended for users with a license agreement for Oracle Solaris 11.3. The guide covers topics such as creating and managing ZFS file systems, configuring storage pools, performing data protection and recovery, and optimizing performance. It also includes information on using ZFS snapshots and clones, managing datasets, and using ZFS encryption. This guide is a valuable resource for system administrators and IT professionals who want to effectively manage ZFS file systems in Oracle Solaris 11.3.

Oracle Solaris ZFS Features

The Oracle Solaris ZFS file system provides features and benefits not found in other file

systems. The following table compares the features of the ZFS file system with traditional file

systems.

Note - For a more detailed discussion of the differences between ZFS and historical file

systems, see Oracle Solaris ZFS and Traditional File System Differences.

TABLE 1

Comparison of the ZFS File System and Traditional File Systems

ZFS File System Traditional File Systems

Uses concept of storage pools created on devices. The pool size

grows as more devices are added to the pool, The additional space is

immediately available for use.

Constrained to one device and to the size of that device.

Volume manager unnecessary. Commands configure pools for data

redundancy over multiple devices.

Supports one file system per user or project for easier management.

Requires volume manager to handle multiple devices to provide data

redundancy, which adds to the complexity of administration.

Uses one file system to manage multiple subdirectories.

Set up and manage many file systems by issuing commands, and

directly apply properties that can be inherited by the descendant file

systems within the hierarchy. No need to edit the /etc/vfstab file.

File system mounts or unmounts are automatic based on file system

properties.

You can create a snapshot, a read-only copy of a file system

or volume quickly and easily. Initially, snapshots consume no

additional disk space within the pool.

Complex administration due to device and size constraints. For

example, every time you add a new file system, you must edit the

/etc/vfstab file.

Metadata is allocated dynamically. No pre-allocation or

predetermined limits are set. The number of supported file systems

is limited only by the available disk space.

Pre-allocation of metadata results in immediate space cost at the

creation of the file system. Pre-allocation also predetermines the

total number of file systems that can be supported.

Uses transactional semantics, where data management uses copy-

on-write semantics, not data overwrite. Any sequence of operations

is either entirely committed or entirely ignored. During accidental

loss of power or a system crash, most recently written pieces of

data might be lost but the file system always remains consistent and

uncorrupted.

Overwrites data in place. File system vulnerable to getting into an

inconsistent state, for example, if the system loses power between

the time a data block is allocated and when it is linked into a

directory. Tools such as fsck command or journaling do not always

guarantee a fix and can introduce unnecessary overhead.

All checksum verification and data recovery are performed at the

file system layer, and are transparent to applications. All failures are

detected and recovery can be performed.

Supports self-healing data through its varying levels of data

redundancy. A bad data block can be repaired by replacing it with

correct data from another redundant copy.

Checksum verification, if provided, is performed on a per-block

basis. Certain failures, such as writing a complete block to an

incorrect location, can result in data that is incorrect but has no

checksum errors.

ACL (Access Control List) model based on NFSv4 specifications to

protect ZFS, similar to NT-style ACL. The model provides a much

In previous Oracle Solaris releases, ACL implementation was based

on POSIX ACL specifications to protect UFS.

16 Managing ZFS File Systems in Oracle Solaris 11.3 • May 2019

Components of a ZFS Storage Pool

ZFS File System Traditional File Systems

more granular set of access privileges. Richer inheritance semantics

designate how access privileges are applied through the directory

hierarchy.

Revised error messaging to reflect ZFS features. For example, for

disk space issues, error messages are more specific to distinguish

between errors involving quota limits and errors due to actual

hardware problems.

Previous Oracle Solaris releases might display more generic

messages. For example, with UFS, disk space problems display only

system full messages.

Components of a ZFS Storage Pool

This section describes the components used for creating ZFS pools.

Using Disks in a ZFS Storage Pool

The most basic element of a storage pool is physical storage. Physical storage can be any block

device of at least 128 MB in size. Typically, this device is a hard drive that is visible to the

system in the /dev/dsk directory.

A storage device can be a whole disk (c1t0d0) or an individual slice (c0t0d0s7). From

management, reliability, and performance perspectives, using whole disks is the easiest and

most efficient way to use ZFS. ZFS formats the whole disk to contain a single, large slice. No

special disk formatting is required. With other methods, such as building pools from disk slices,

LUNs in hardware RAID arrays, or volumes presented by software-based volume managers,

management becomes increasingly complex and might provide less-than-optimal performance.

Caution - Because of potential complexity in managing slices for storage pools, avoid using

slices.

The format command displays the partition table of disks. When Oracle Solaris is installed on

a SPARC

system with GPT aware firmware, an EFI (GPT) label is applied to the disk. The

partition table would be similar to the following example:

Current partition table (original):

Total disk sectors available: 143358287 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector

0 usr wm 256 68.36GB 143358320

Chapter 1 • Introducing the Oracle Solaris ZFS File System 17

Components of a ZFS Storage Pool

1 unassigned wm 0 0 0

2 unassigned wm 0 0 0

3 unassigned wm 0 0 0

4 unassigned wm 0 0 0

5 unassigned wm 0 0 0

6 unassigned wm 0 0 0

8 reserved wm 143358321 8.00MB 143374704

When Oracle Solaris is installed on an x86 based system, in most cases a EFI (GPT) label is

applied to root pool disks. The partition table would be similar to the following:

Current partition table (original):

Total disk sectors available: 27246525 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector

0 BIOS_boot wm 256 256.00MB 524543

1 usr wm 524544 12.74GB 27246558

2 unassigned wm 0 0 0

3 unassigned wm 0 0 0

4 unassigned wm 0 0 0

5 unassigned wm 0 0 0

6 unassigned wm 0 0 0

8 reserved wm 27246559 8.00MB 27262942

In the output, partition 0 (BIOS boot) contains required GPT boot information. Similar to

partition 8, partition 0 requires no administration and should not be modified. The root file

system is contained in partition 1.

Note - For more information about EFI labels, see “EFI (GPT) Disk Label” in Managing

Devices in Oracle Solaris 11.3.

On an x86 based system, the disk must have a valid Solaris fdisk partition. For more

information about creating or changing an Oracle Solaris fdisk partition, see “Configuring

Disks” in Managing Devices in Oracle Solaris 11.3.

Disk names generally follow the /dev/dsk/cNtNdN naming convention. Some third-party

drivers use a different naming convention or place disks in a location other than the /dev/dsk

directory. To use these disks, you must manually label the disk and allocate it to ZFS.

You can specify disks by using either the full path or a shorthand name that consists of the

device name within the /dev/dsk directory. The following examples show valid disk names:

■

c1t0d0

■

/dev/dsk/c1t0d0

■

/dev/tools/disk

18 Managing ZFS File Systems in Oracle Solaris 11.3 • May 2019

Redundancy Features of a ZFS Storage Pool

■

Double-parity (raidz2) – Similar to RAID-6.

■

Triple-parity (raidz3) – For more information, see Triple-Parity RAID and Beyond (https:

//queue.acm.org/detail.cfm?id=1670144).

In RAID-Z, ZFS uses variable-width RAID stripes so that all writes are full-stripe writes. ZFS

integrates file system and device management in such a way that the file system's metadata

has enough information about the underlying data redundancy model to handle variable-width

RAID stripes. Thus, RAID-Z avoids issues encountered in traditional RAID algorithms such as

RAID-5's write hole problem.

ZFS provides self-healing data in a mirrored or RAID-Z configuration. When a bad data block

is detected, ZFS fetches the correct data from another redundant copy and repairs the bad data

by replacing it with the good copy.

A RAID-Z configuration with n disks of size x with p parity disks can hold approximately

(n-p)*x bytes and can withstand p devices failing before data integrity is compromised. You

need at least two disks for a single-parity RAID-Z configuration and at least three disks for

a double-parity RAID-Z configuration, and so on. For example, if you have three disks in a

single-parity RAID-Z configuration, parity data occupies disk space equal to one of the three

disks. Otherwise, no special hardware is required to create a RAID-Z configuration.

Just like mirrored configurations, RAID-Z configurations can either be simple or complex.

If you are creating a RAID-Z configuration with many disks, consider splitting the disks into

multiple groupings. For example, a RAID-Z configuration with 14 disks is better split into

two 7-disk groupings. RAID-Z configurations with single-digit groupings of disks commonly

perform better.

See the following sources for more information:

■

“Creating a RAID-Z Storage Pool” on page 33 – provides information about creating a

RAID-Z storage pool.

■

https://blogs.oracle.com/roch/when-to-and-not-to-use-raid-z.: – presents

guidelines on choosing between a mirrored configuration or a RAID-Z configuration based

on performance and disk space considerations.

■

Chapter 12, “Recommended Oracle Solaris ZFS Practices” – covers additional RAID-Z

storage pool recommendations.

ZFS Hybrid Storage Pool

The ZFS hybrid storage pool, available in Oracle's Sun Storage 7000 product series, combines

DRAM, SSDs, and HDDs to improve performance and increase capacity, while reducing power

20 Managing ZFS File Systems in Oracle Solaris 11.3 • May 2019

剩余289页未读，继续阅读

weixin_40191861_zj

粉丝: 86
资源: 1万+

"Oracle Solaris 11.3 ZFS文件系统管理手册"

Oracle Solaris 11 Oracle Solaris Administration:ZFS File Systems

Oracle Solaris 11.3 Managing File Systems-92

Oracle Solaris 11.3 Managing Network File Systems-186

Oracle Solaris 11.3 Managing Secure Shell Access -62

Oracle Solaris 11.3 Managing Remote Systems-30

Oracle Solaris 11.2 Managing ZFS File Systems in Oracle Solaris

Oracle Solaris 11.3 Managing Devices in Oracle Solaris 11.3-282

Oracle Solaris 11.3 Managing Auditing in Oracle Solaris 11.3-16

Oracle Solaris 11.3 Managing System Services -128

Oracle Solaris 11.3 Managing sendmail Services-114

最新资源