Unsolved
This post is more than 5 years old
40 Posts
0
967
May 27th, 2011 09:00
Thin pool allocated is smaller than Total Written
Here is the CLI o/p for command,
symcfg -sid xxxx list -pool -thin -detail -all -v -mb:
-----------------------------------------------------------------------
Pool Pool Total
Sym Total Subs Allocated Written
Dev MBs (%) MBs (%) MBs (%) Status
-----------------------------------------------------------------------
0346 984844 9 59795 6 256928 26 Bound
034A 984844 9 61601 6 258283 26 Bound
034E 984844 9 57896 6 256151 26 Bound
As we can observe 'Pool allocated' is much smaller than 'Total Written' capacity. Can someone please let me know the reason?
(SYMCLI) Version V7.2.0.0
Model: VMAX-1SE
Pool Type : Thin
Dev Emulation : FBA
Dev Configuration : 2-Way Mir
Pool State : Enabled
# of Devices in Pool : 432
# of Enabled Devices in Pool : 432
Max. Subscription Percent : 150
Rebalance Variance : 1%
Max devs per rebalance scan : 256
Ashit
40 Posts
0
June 13th, 2011 06:00
Can someone please reply/comment here?
Which capacity should be considered as the consumed size of thin luns and why is there huge difference in the two values. Was there any issue with V7.2.0 which fixed with newer release?
I have opened a service request question 41447078 too for the same.
--Ashit
RobertDudley
2 Intern
•
448 Posts
0
June 13th, 2011 07:00
Pool Allocated in MB - number of MB allocated from the data device pool for exclusive use by this device
Total written cap - number of allcoated MB in the data device pool that the device has actually used
I do not see how the one number could be larger that the other. I cant do a comparison as we pre-aalocate all lun in the thin pool when we create them. Have you recently added data dev's to the pool? Also we are on 7.2.1.3 for SMC and SE.
Ashit
40 Posts
0
June 30th, 2011 10:00
Can it be because of FAST-VP feature on this array?
I am looking the 'Other pool bound devices' section in the command o/p which seems to list the devices which actually belong to different pool but consume storage from this pool.
Thanks
Ashit
MDSchneider
25 Posts
0
July 1st, 2011 13:00
The legitimate reason is FAST VP, the policy has moved some of the allocation into another pool. You also could have run a VLUN migration that didn't finish for some reason.