Cache tab missing in LUN properties

i have never bothered to disable read/write cache for pool LUNs but looking at pool LUN properties i dont' think you can. That tells me it's always enabled for pool LUNs.

Fast cache for pool LUNs cannot be manipulated at LUN level.

If I disable FAST cache on the pool as I do not have SSDs I still cannot verify whether the SP Read cache is on or off on a pool LUN as I cannot see the Cache tab and the Statistics window does not show any cache statistics.

i don't see SP Cache read hits/misses for Pool LUNs in Unisphere Analyzer either.

I dont't want to turn it off either but I cannot verify just assume it is on. Also the monitoring tool does not report any read/write cache hit statistics for any pool LUNs just raid-group LUNs so I'm a bit confused whether this is normal or I did not enable something somewhere.

I have run the storage verification wizard and collected configuration/diagnostic data and that shows N/A for cache information on pool LUNs so I assume this is the way it works, and it is normal.

Thank you for your help.

I've noticed the same in Monitoring and Reporting version 1.01  Its frustrating as we'd like to get some idea of cache hits across the Pool LUNs to know if sizing is correct.  I guess cache hits are recorded at the pool level rather than the LUN level, but this information remains a mystery.  

I'm also keen to see some reporting regarding tiering movements.  There must be a whitepaper somewhere so I'll do some digging.  I did find this article which looks interesting, but surely we don't have to delve into the CLI to get useful data...

http://emcsan.wordpress.com/2011/06/03/tiering-reports-for-emcs-fast-vp/

tamasm1,

In regards to pools, if you are interested in verifying the state of SP Cache, you will instead want to identify the private FLARE LUNs and run the getlun command against those instead.  As a reminder, fundamentally a pool is made up of private RAID Group(s) and private LUNs.  The 1GB extents that make up the pool LUNs are then distributed across them (an entire single 1GB extent only exists on one of the private RAID groups).

1) First identify the private RAID Groups that make up the pool:

naviseccli –h getrg -<engineering password>

NOTE: even though the engineering password wasn't really meant to be kept secret but more of an acknowledgement by the user that they are making an effort to bypass certain controls, so as not to alert the password-police, it is instead an exercise for the user to locate it

If you are interested in the logic behind the creation of the private groups upon pool creation (or expansion), the workflow is documented here:

https://community.emc.com/message/696115#696115

2) Identify the private LUNs:

The getrg command (along with the engineering password), will list every RAID Group including the private RG's from the storage pools (and even the private R1 RG pairs of your FAST Cache if applicable).  To identify those that make up the pool in question, simply identify them by the individual disks in the output: “List of disks”.

Then from the getrg output, you need to run the getlun command (again with the engineering password) for the private LUNs (as provided in the “List of LUNS”) for that private RG as follows:

naviseccli –h getlun -<engineering password>

As you would probably surmise on your own from the pattern, the private LUNs are bound as follows:

a) quantity of private LUNs = 2x the number of drives in the private RG

b) equal sized consuming all usable capacity of private RG

b) SP ownership balanced between A and B

Specific to your original question, you will want to confirm the status of the following:

a) Write cache: ENABLED

b) Read cache: ENABLED

Keeping in mind, since they are FLARE LUNs, you can also see other various statistics that you have become familiar with such as Read cache hits, Write cache hits, etc, but again it is for the private LUNs that host the 1GB extents that make up the pool LUNs.