This feels like it should be a very basic Storage Guy question that I should already know the answer to, but I'm not having a lot of luck so far.
A certain volume hit 93% usage, which threw an alert. By the time I looked at it, it was down to 90%, which is fine. It prompted me to look further into that volume though, and some numbers aren't adding up.
The volume hosts a handful of iSCSI LUNs. The percent-used value is still 90%. The percent-physical-used value is 20%. The volume show-space command shows 30% used (because of the +10% snapshot reserve). There's no snapshot spillover - I'm currently using less than half the reserve. What distinguishes one of the used percent values from another? How can I account for the difference?
Below is the output of the vol show -instance, and the vol show-space. Relevant items are highlighted. Thanks!
Vserver Name: [redacted] Volume Name: [redacted] Aggregate Name: [redacted] Volume Size: 50TB Volume Data Set ID: 1589 Volume Master Data Set ID: 2147485245 Volume State: online Volume Type: RW Volume Style: flex Is Cluster-Mode Volume: true Is Constituent Volume: false Export Policy: default User ID: 0 Group ID: 0 Security Style: unix UNIX Permissions: ---rwxr-xr-x Junction Path: - Junction Path Source: - Junction Active: - Junction Parent Volume: - Comment: [redacted] Available Size: 4.71TB Filesystem Size: 50TB Total User-Visible Size: 45TB Used Size: 9.87TB Used Percentage: 90% Volume Nearly Full Threshold Percent: 95% Volume Full Threshold Percent: 98% Maximum Autosize (for flexvols only): 50TB (DEPRECATED)-Autosize Increment (for flexvols only): 100GB Minimum Autosize: 38.76TB Autosize Grow Threshold Percentage: 92% Autosize Shrink Threshold Percentage: 50% Autosize Mode: grow Autosize Enabled (for flexvols only): true Total Files (for user-visible data): 31876689 Files Used (for user-visible data): 166 Space Guarantee Style: none Space Guarantee in Effect: true Snapshot Directory Access Enabled: true Space Reserved for Snapshot Copies: 10% Snapshot Reserve Used: 43% Snapshot Policy: 3dailys Creation Time: Tue Apr 12 15:45:58 2016 Language: C.UTF-8 Clone Volume: false Node name: [redacted] NVFAIL Option: on Volume's NVFAIL State: false Force NVFAIL on MetroCluster Switchover: off Is File System Size Fixed: false Extent Option: off Reserved Space for Overwrites: 0B Fractional Reserve: 0% Primary Space Management Strategy: volume_grow Read Reallocation Option: off Inconsistency in the File System: false Is Volume Quiesced (On-Disk): false Is Volume Quiesced (In-Memory): false Volume Contains Shared or Compressed Data: true Space Saved by Storage Efficiency: 11.38TB Percentage Saved by Storage Efficiency: 54% Space Saved by Deduplication: 1.72TB Percentage Saved by Deduplication: 8% Space Shared by Deduplication: 1.57TB Space Saved by Compression: 9.66TB Percentage Space Saved by Compression: 45% Volume Size Used by Snapshot Copies: 2.15TB Block Type: 64-bit Is Volume Moving: false Flash Pool Caching Eligibility: read-write Flash Pool Write Caching Ineligibility Reason: - Managed By Storage Service: - Create Namespace Mirror Constituents For SnapDiff Use: - Constituent Volume Role: - QoS Policy Group Name: - Caching Policy Name: auto Is Volume Move in Cutover Phase: false Number of Snapshot Copies in the Volume: 3 VBN_BAD may be present in the active filesystem: false Is Volume on a hybrid aggregate: true Total Physical Used Size: 9.83TB Physical Used Percentage: 20%
[cluster]::> vol show-space [redacted]
Vserver : [redacted] Volume : [redacted]
Feature Used Used% -------------------------------- ---------- ------ User Data 9.70TB 19% Filesystem Metadata 27.93GB 0% Inodes 128KB 0% Snapshot Reserve 5TB 10% Deduplication 72.02GB 0% Performance Metadata 72.03GB 0%
The sum of all snapshots is 1506GB, which is less than the snapshot reserve of 5120GB.
Some LUNs are thin provisioned and some aren't. The correct sum of LUNs, near as I can tell, is 21605GB (i.e., the LUN size of thick LUNs plus the used size of thin LUNs)
That sum of LUNs (21605) and the snapshot reserve (5120GB) is 26725GB, or about 52% of the total volume (51200GB). That percentage value doesn't align to any other figure present, so maybe I'm mistaken there.
I may not have a clear idea of how dedupe and compression interact with any of the "used percentage" figures CDOT coughs up.
Right, yep, a couple of thick provisioned LUNs in a thin provisioned volume, which isn't ideal, but it's what I've got.
So, if I've tallied everything correctly that should be present, I have something like:
3902GB of thick provisioned LUNs (lun show -volume VOL -space-reserve enabled -fields size)
17703GB of used capacity in thin provisioned LUNs (lun show -volume VOL -space -reserve disabled -fields size-used)
5120GB of snapshot reserve (less than 100% of which is used)
This sums to 24433GB, which is 47.7% of the 51200GB volume. That figure doesn't align with any other percentage figure I can summon from the NetApp:
89% used, 10009GB used, 9378GB physical-used, 5230GB available (vol show VOL -fields size,used,percent-used,available,physical-used)
30% total used (15129GB used, which aligns w/ 10009GB "used" from previous command + 5120GB snapshot reserve) (vol show-space VOL)
The real outlier here is that big 89% used value. How can I be using 15129GB/51200GB and that shakes out to 89% usage? Is it all down to "something weird" about having thick provisioned LUNs inside a thin provisioned volume? Is it worth opening a ticket to NetApp to confirm?
"The real outlier here is that big 89% used value. How can I be using 15129GB/51200GB and that shakes out to 89% usage? Is it all down to "something weird" about having thick provisioned LUNs inside a thin provisioned volume? Is it worth opening a ticket to NetApp to confirm?"
Feel free to open the ticket.. if they can find a different answer.. keep us updated.
Simple answer is.. your volume DONT have 51200GB until you write that much data to it... again.. because, your volume is thin provisioned.
So just tallying the number against 51200GB dont work while you have a thin provisioned volume.