Transitioning From Oracle® Solaris 10 to Oracle Solaris 11.2

Exit Print View

Updated: December 2014
 
 

ZFS Storage Pool Creation Best Practices

  • Specific root pool device and boot disk requirements

  • General root pool creation best practices

    • You must create the root pool must as a mirrored configuration or as a single-disk configuration. Neither a RAID-Z nor a striped configuration is supported. You cannot add additional disks to create multiple mirrored top-level virtual devices by using the zpool add command. To expand a mirrored virtual device, use the zpool attach command.

    • The root pool cannot have a separate log device.

    • You can set pool properties during an installation with AI by using the pool_options keyword syntax, but the gzip compression algorithm is not supported on root pools.

    • Do not rename the root pool after it is created by an initial installation. Renaming the root pool might result in an unbootable system.

    • Do not create a root pool on a USB stick for a production system because root pool disks are critical for continuous operation, particularly in an enterprise environment. Consider using a system's internal disks for the root pool, or at least use, the same quality disks that you would use for your non-root data. In addition, a USB stick might not be large enough to support a dump volume size that is equivalent to at least 1/2 the size of physical memory.

    • Consider keeping root pool components separate from non-root pool data.

  • Non-root pool creation best practices

    Create non-root pools with whole disks by using the d* identifier. Do not use the p* identifier.

    • ZFS works best without any additional volume management software.

    • For better performance, use individual disks or at least LUNs made up of just a few disks. By providing ZFS with more visibility into the LUN setup, ZFS is able to make better I/O scheduling decisions.

    • Mirrored storage pools – Consume more disk space but generally perform better with small random reads. For example:

      # zpool create tank mirror c1d0 c2d0 mirror c3d0 c4d0

      Mirrored storage pools are also more flexible in that you can detach, attach, and replace existing devices in the pool.

    • RAID-Z storage pools

      You can create RAID-Z storage pools with 3 parity strategies, where parity equals 1 (raidz), 2 (raidz2), or 3 (raidz3).

      • A RAID-Z configuration maximizes disk space and generally performs well when data is written and read in large chunks (128K or more). Create a single-parity RAIDZ (raidz) configuration at 3 disks (2+1).

      • A RAIDZ-2 configuration offers better data availability, and performs similarly to RAID-Z. RAIDZ-2 has significantly better mean time to data loss (MTTDL) than either RAID-Z or 2-way mirrors. Create a double-parity RAID-Z (raidz2) configuration at 6 disks (4+2).

      • A RAIDZ-3 configuration maximizes disk space and offers excellent availability because it can withstand 3 disk failures. Create a triple-parity RAID-Z (raidz3) configuration at 8 disks (5+3).

  • Non-redundant pools

    If you create a non-redundant pool, you will see a message similar to the following:

    # zpool create pond c8t2d0 c8t3d0
    'pond' successfully created, but with no redundancy; failure of one
    device will cause loss of the pool

    Creating a pool with no redundancy is not recommended because a device failure could mean that the data is unrecoverable. Consider creating a ZFS storage pool with redundancy as follows:

    # zpool create pond mirror c8t2d0 c8t3d0