1. Managing ZFS File Systems in Oracle Solaris 11.4
  2. Recommended Oracle Solaris ZFS Practices
  3. Recommended Storage Pool Practices
  4. General System Practices

General System Practices

  • Keep system up-to-date with latest Oracle Solaris updates and releases

  • Confirm that your controller honors cache flush commands so that you know your data is safely written, which is important before changing the pool's devices or splitting a mirrored storage pool. This is generally not a problem on Oracle/Sun hardware, but it is good practice to confirm that your hardware's cache flushing setting is enabled.

  • Size memory requirements to actual system workload

    • With a known application memory footprint, such as for a database application, you might cap the ARC size so that the application will not need to reclaim its necessary memory from the ZFS cache.

    • Consider deduplication memory requirements

    • Identify ZFS memory usage with the following command:

      $ mdb -k
> ::memstat
Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     388117              1516   19%
ZFS File Data               81321               317    4%
Anon                        29928               116    1%
Exec and libs                1359                 5    0%
Page cache                   4890                19    0%
Free (cachelist)             6030                23    0%
Free (freelist)           1581183              6176   76%

Total                     2092828              8175
Physical                  2092827              8175
> $q

    • See Document 1663862.1, Memory Management Between ZFS and Applications in Oracle Solaris 11.x, in My Oracle Support (MOS) for tips on tuning the ZFS ARC cache. This document includes a script which you can use to modify the user_reserve_hint_pct and the zfs_arc_max_percent parameters.

    • Consider using ECC memory to protect against memory corruption. Silent memory corruption can potentially damage your data.

  • Perform regular backups – 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. If your data is important, it should be backed up. Different ways to provide copies of your data are:

    • Regular or daily ZFS snapshots

    • Weekly backups of ZFS pool data. You can use the zpool split command to create an exact duplicate of ZFS mirrored storage pool.

    • Monthly backups by using an enterprise-level backup product

  • Hardware RAID

    • ZFS redundancy is recommended over hardware RAID for the following reasons:

      • When ZFS manages the storage redundancy, it not only detects underlying hardware issues but can also repair data inconsistencies.

      • Using ZFS redundancy has many benefits. For production environments, configure ZFS so that it can repair data inconsistencies. Use ZFS redundancy, such as RAID-Z, RAID-Z-2, RAID-Z-3, or mirroring. With such redundancy, faults in the underlying storage device or its connections to the host can be discovered and repaired by ZFS.

    • If you must use hardware RAID, present devices in JBOD mode so ZFS can manage the redundancy. In addition, follow these recommendations:

      • Monitor both the ZFS storage pool by using zpool status and the underlying LUNs by using your hardware RAID monitoring tools.

      • Promptly replace any failed devices.

      • Scrub your ZFS storage pools routinely, such as monthly, if you are using datacenter quality services.

      • Always have good, recent backups of your important data.

    See also Pool Creation Practices on Local or Network Attached Storage Arrays.

  • Crash dumps consume more disk space, generally in the 1/2-3/4 size of physical memory range.