To create a storage pool, use the zpool create command. This command takes a pool name and any number of virtual devices as arguments. The pool name must satisfy the naming requirements in ZFS Component Naming Requirements.
The following command creates a new pool named tank that consists of the disks c1t0d0 and c1t1d0:
# zpool create tank c1t0d0 c1t1d0
Device names representing the whole disks are found in the /dev/dsk directory and are labeled appropriately by ZFS to contain a single, large slice. Data is dynamically striped across both disks.
To create a mirrored pool, use the mirror keyword, followed by any number of storage devices that will comprise the mirror. Multiple mirrors can be specified by repeating the mirror keyword on the command line. The following command creates a pool with two, two-way mirrors:
# zpool create tank mirror c1d0 c2d0 mirror c3d0 c4d0
The second mirror keyword indicates that a new top-level virtual device is being specified. Data is dynamically striped across both mirrors, with data being redundant between each disk appropriately.
For more information about recommended mirrored configurations, see Chapter 11, Recommended Oracle Solaris ZFS Practices.
Currently, the following operations are supported in a ZFS mirrored configuration:
Adding another set of disks for an additional top-level virtual device (vdev) to an existing mirrored configuration. For more information, see Adding Devices to a Storage Pool.
Attaching additional disks to an existing mirrored configuration. Or, attaching additional disks to a non-replicated configuration to create a mirrored configuration. For more information, see Attaching and Detaching Devices in a Storage Pool.
Replacing a disk or disks in an existing mirrored configuration as long as the replacement disks are greater than or equal to the size of the device to be replaced. For more information, see Replacing Devices in a Storage Pool.
Detaching a disk in a mirrored configuration as long as the remaining devices provide adequate redundancy for the configuration. For more information, see Attaching and Detaching Devices in a Storage Pool.
Splitting a mirrored configuration by detaching one of the disks to create a new, identical pool. For more information, see Creating a New Pool By Splitting a Mirrored ZFS Storage Pool.
You cannot outright remove a device that is not a spare, a log device, or a cache device from a mirrored storage pool.
Consider the following root pool configuration requirements:
In Oracle Solaris, disks that are used for the root pool are installed with an EFI (GPT) label on an x86 based system, a supported SPARC system with GPT aware firmware, or an SMI (VTOC) label is applied on a SPARC based system without GPT aware firmware. The installer applies an EFI (GPT) label if possible and if you need to recreate a ZFS root pool after installation, you can use the following command to apply the EFI (GPT) disk label and the correct boot information:
# zpool create -B rpool2 c1t0d0
The root pool must be created as a mirrored configuration or as a single-disk configuration. You cannot add additional disks to create multiple mirrored top-level virtual devices by using the zpool add command, but you can expand a mirrored virtual device by using the zpool attach command.
A RAID-Z or a striped configuration is not supported.
The root pool cannot have a separate log device.
If you attempt to use an unsupported configuration for a root pool, you see messages similar to the following:
ERROR: ZFS pool <pool-name> does not support boot environments
# zpool add -f rpool log c0t6d0s0 cannot add to 'rpool': root pool can not have multiple vdevs or separate logs
For more information about installing and booting a ZFS root file system, see Chapter 4, Managing ZFS Root Pool Components.
Creating a single-parity RAID-Z pool is identical to creating a mirrored pool, except that the raidz or raidz1 keyword is used instead of mirror. The following example shows how to create a pool with a single RAID-Z device that consists of five disks:
# zpool create tank raidz c1t0d0 c2t0d0 c3t0d0 c4t0d0 /dev/dsk/c5t0d0
This example illustrates that disks can be specified by using their shorthand device names or their full device names. Both /dev/dsk/c5t0d0 and c5t0d0 refer to the same disk.
You can create a double-parity or triple-parity RAID-Z configuration by using the raidz2 or raidz3 keyword when creating the pool. For example:
# zpool create tank raidz2 c1t0d0 c2t0d0 c3t0d0 c4t0d0 c5t0d0 # zpool status -v tank pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 c1t0d0 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 c3t0d0 ONLINE 0 0 0 c4t0d0 ONLINE 0 0 0 c5t0d0 ONLINE 0 0 0 errors: No known data errors
# zpool create tank raidz3 c0t0d0 c1t0d0 c2t0d0 c3t0d0 c4t0d0 c5t0d0 c6t0d0 c7t0d0 c8t0d0 # zpool status -v tank pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz3-0 ONLINE 0 0 0 c0t0d0 ONLINE 0 0 0 c1t0d0 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 c3t0d0 ONLINE 0 0 0 c4t0d0 ONLINE 0 0 0 c5t0d0 ONLINE 0 0 0 c6t0d0 ONLINE 0 0 0 c7t0d0 ONLINE 0 0 0 c8t0d0 ONLINE 0 0 0 errors: No known data errors
Currently, the following operations are supported in a ZFS RAID-Z configuration:
Adding another set of disks for an additional top-level virtual device to an existing RAID-Z configuration. For more information, see Adding Devices to a Storage Pool.
Replacing a disk or disks in an existing RAID-Z configuration as long as the replacement disks are greater than or equal to the size of the device to be replaced. For more information, see Replacing Devices in a Storage Pool.
Currently, the following operations are not supported in a RAID-Z configuration:
Attaching an additional disk to an existing RAID-Z configuration.
Detaching a disk from a RAID-Z configuration, except when you are detaching a disk that is replaced by a spare disk or when you need to detach a spare disk.
You cannot outright remove a device that is not a log device or a cache device from a RAID-Z configuration. An RFE is filed for this feature.
For more information about a RAID-Z configuration, see RAID-Z Storage Pool Configuration.
The ZFS intent log (ZIL) is provided to satisfy POSIX requirements for synchronous transactions. For example, databases often require their transactions to be on stable storage devices when returning from a system call. NFS and other applications can also use fsync() to ensure data stability.
By default, the ZIL is allocated from blocks within the main pool. However, better performance might be possible by using separate intent log devices, such as NVRAM or a dedicated disk.
Consider the following points when determining whether setting up a ZFS log device is appropriate for your environment:
Log devices for the ZFS intent log are not related to database log files.
Any performance improvement seen by implementing a separate log device depends on the device type, the hardware configuration of the pool, and the application workload. For preliminary performance information, see this blog:
http://blogs.oracle.com/perrin/entry/slog_blog_or_blogging_on
Log devices can be unreplicated or mirrored, but RAID-Z is not supported for log devices.
If a separate log device is not mirrored and the device that contains the log fails, storing log blocks reverts to the storage pool.
Log devices can be added, replaced, removed, attached, detached, imported, and exported as part of the larger storage pool.
You can attach a log device to an existing log device to create a mirrored log device. This operation is identical to attaching a device in a unmirrored storage pool.
The minimum size of a log device is the same as the minimum size of each device in a pool, which is 64 MB. The amount of in-play data that might be stored on a log device is relatively small. Log blocks are freed when the log transaction (system call) is committed.
The maximum size of a log device should be approximately 1/2 the size of physical memory because that is the maximum amount of potential in-play data that can be stored. For example, if a system has 16 GB of physical memory, consider a maximum log device size of 8 GB.
You can set up a ZFS log device when the storage pool is created or after the pool is created.
The following example shows how to create a mirrored storage pool with mirrored log devices:
# zpool create datap mirror c0t5000C500335F95E3d0 c0t5000C500335F907Fd0 \
mirror c0t5000C500335BD117d0 c0t5000C500335DC60Fd0 \
log mirror c0t5000C500335E106Bd0 c0t5000C500335FC3E7d0
# zpool status datap
pool: datap
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
datap ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t5000C500335F95E3d0 ONLINE 0 0 0
c0t5000C500335F907Fd0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t5000C500335BD117d0 ONLINE 0 0 0
c0t5000C500335DC60Fd0 ONLINE 0 0 0
logs
mirror-2 ONLINE 0 0 0
c0t5000C500335E106Bd0 ONLINE 0 0 0
c0t5000C500335FC3E7d0 ONLINE 0 0 0
errors: No known data errorsFor information about recovering from a log device failure, see Example 10–2.
Cache devices provide an additional layer of caching between main memory and disk. Using cache devices provides the greatest performance improvement for random-read workloads of mostly static content.
You can create a storage pool with cache devices to cache storage pool data. For example:
# zpool create tank mirror c2t0d0 c2t1d0 c2t3d0 cache c2t5d0 c2t8d0
# zpool status tank
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c2t0d0 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
c2t3d0 ONLINE 0 0 0
cache
c2t5d0 ONLINE 0 0 0
c2t8d0 ONLINE 0 0 0
errors: No known data errorsAfter cache devices are added, they gradually fill with content from main memory. Depending on the size of your cache device, it could take over an hour for the device to fill. Capacity and reads can be monitored by using the zpool iostat command as follows:
# zpool iostat -v pool 5
Cache devices can be added or removed from a pool after the pool is created.
Consider the following points when determining whether to create a ZFS storage pool with cache devices:
Using cache devices provides the greatest performance improvement for random-read workloads of mostly static content.
Capacity and reads can be monitored by using the zpool iostat command.
Single or multiple cache devices can be added when the pool is created. They can also be added and removed after the pool is created. For more information, see Example 3–4.
Cache devices cannot be mirrored or be part of a RAID-Z configuration.
If a read error is encountered on a cache device, that read I/O is reissued to the original storage pool device, which might be part of a mirrored or a RAID-Z configuration. The content of the cache devices is considered volatile, similar to other system caches.
Review the following cautions when creating and managing ZFS storage pools.
Do not repartition or relabel disks that are part of an existing storage pool. If you attempt to repartition or relabel a root pool disk, you might have to reinstall the OS.
Do not create a storage pool that contains components from another storage pool, such files or volumes. Deadlocks can occur in this unsupported configuration.
A pool created with a single slice or single disk has no redundancy and is at risk for data loss. A pool created with multiple slices but no redundancy is also at risk for data loss. A pool created with multiple slices across disks is harder to manage than a pool created with whole disks.
A pool that is not created with ZFS redundancy (RAID-Z or mirror) can only report data inconsistencies. It cannot repair data inconsistencies.
Although a pool that is created with ZFS redundancy can help reduce down time due to hardware failures, it is not immune to hardware failures, power failures, or disconnected cables. Make sure you backup your data on a regular basis. Performing routine backups of pool data on non-enterprise grade hardware is important.
A pool cannot be shared across systems. ZFS is not a cluster file system.