FS System: Thin Provisioning Is Not a Best Practice for UNIX File Systems

Asset ID:	1-79-2074104.1
Update Date:	2016-12-01
Keywords:

Solution Type Predictive Self-Healing Sure

Solution 2074104.1 : FS System: Thin Provisioning Is Not a Best Practice for UNIX File Systems

Applies to:

Oracle FS1-2 Flash Storage System - Version 6.1 and later
Information in this document applies to any platform.

Purpose

Explain why thin provisioning is not best fit with UNIX filesystems.

Scope

Details

Thin provisioning feature is available on Oracle FS System for LUNs that would not need whole capacity at creation time. Thin provisioned LUN appears to have all of the storage space that the volume has been given in "Addressable logical capacity" field. But only space given in "Allocated logical capacity" will be physically allocated on drive enclosures.

Oracle FS system will automatically allocate more space when LUN needs more space overtime. The automatic allocation of additional capacity to a thin provisioned LUN is called infill. This additional capacity might not be contiguous with the previous allocations.

Most of the filesystems used on UNIX/Linux Operating Systems need all of the addressable space of a LUN. Thinly provisioned LUNs will have to be fully allocated on the FS Storage when used by Unix filesystems, because make filesystem utilities (mkfs/newfs) want to initialize all blocks and record superblock information during filesystem creation.

When make filesystem (mkfs/newfs) executes on any Unix system for Thin Provisioned LUN, FS System will start infill operations to make available all proposed blocks of the LUN. This might saturate the controllers with infill task internally via consuming all CPU/memory resources. If the FS system is running on code level below 6.1.18 the Controllers may warmstart as they cannot execute other vital tasks in a timely manner while executing infill operations.

If the LUN has been used in this way -created as a Thin Provisioned LUN, then created a filesystem on it- it would look like a fragmented LUN in very small pieces on the FS Storage. The system attempts to coalesce the existing thousands of small extents into fewer larger extents and there will be additional performance impacts on the daily coalesce scan. This impact will continue until the system has managed to coalesce [similar to defragment] the storage for those large LUNs.

If the LUNs are not in production yet we recommend to execute the below steps to re-create the LUNs:

Delete the existing allocations.
Wait until zeroing complete, zeroing can be monitored on "Tasks" screen in GUI.
Then recreate those LUNs as fully allocated LUNs.

If the LUNs are in production, the FS System will coalesce the LUNs by time.
It is not possible to monitor this activity on system. Simply do not use Thin Provisioning for unix filesystems.

Auto-tier LUNs are thin provisioned by default. If you are using Auto-tier LUNs for UNIX file systems you need to change default allocation options during LUN creation. Fully provisioned Auto-tier LUNs might not get full benefits of auto-tiering.
For more information please check Document 2035830.1 FS System: Best Practices Whitepaper on Configuring QoS Plus for the FS1-2.

References

<BUG:21798020> - OVERDRIVING INFILL CAN LEAD TO STALE TASK HEALTH CHECK AND WARMSTART
<NOTE:2035830.1> - FS System: Best Practices Whitepaper on Configuring QoS Plus for the FS1-2

Attachments

This solution has no attachment