Reconfiguring FAST Cache

1 - You assumptions here are correct, this will stop FAST Cache and System Cache during the re-configuration.

2 - The percentage of memory overhead for FAST Cache is used for the memory map and is allocated in 64k chunks.  This scales in a linnear fashion, so if you are scaling exactly double, you should expect to see double the hit on space.

3 - Should not need to modify the config for the standard cache.

Please note, that if you disable and re-enable FAST, you will have to go back through all your FAST enabled LUNs and re-enable them to use FAST again I believe.

I suspect i would have to minimize IO traffic when performing the FAST Cache configuration because it system cache gets disabled?

tkjoffs - there is no reason why you would have to go through all your "FAST enabled LUNs" because you are reconfiguring your FAST Cache. Why did you think you would have to do that? If there is any documentation which mentions that, let us know so that we can get it corrected.

Yes, since you are disabling FAST Cache for some time, you should plan to reconfigure the FAST Cache during a low activity period.

You should also look at distributing the EFD disks across the back-end buses - don't put the disks all on one bus - you could overload it.

glen

I was under the impression that if you destroy your Fast cache it will disable it on the existing LUNs. Hence the same would apply as if you are installing a FAST cache for the first time - anything provisioned before it is configured would be disabled by default???

If not, even better.

just destroyed fast cache on my 5700,  fast cache option remained available and checked on LUNs.

you could try your friendly EMC account rep

Thanks! Nice to know. Okay, where can I get a lab array? Free hopefully…. J

@kelleg--good advice. if i remember correctly, EFD can co-exist with FC drives?

yes, FC and EFD can co-exist on CX4 in the same DAE

tkjoffs,

I'm thinking maybe you are confusing the enable/disable situation regarding FAST Cache and existing FLARE LUNs or Pools with the behavior as follows:

1) Array initialized without FAST Cache

2) FLARE LUNs and/or Pools are created

3) Client then purchases FAST Cache

4) FAST Cache Enabler is loaded and EFD drives are configured as FAST Cache

In this situation, all of the FLU's (on traditional RG's) and Pools created prior to when FAST Cache was configured will need to be revisited and enabled to take advantage of the extended cache.

Just a thought, my apologies if this is already known.

>> Hence the same would apply as if you are installing a FAST cache for the first time - anything provisioned before it is configured would be disabled by default???

Sorry, you did mention this behavior in your original post.  Apologies for the noise.  Ignore.

>> You should also look at distributing the EFD disks across the back-end buses - don't put the disks all on one bus - you could overload it.

Probably also worth mentioning that once physically separated across back-end buses, for FAST Cache it is recommended that the primary and its mirror are on different back-end buses for each of the (private) RAID 1 RG's that get created from the selected drives.  This is accomplished by adding the drives one at a time in the "FAST Cache" tab and will be bound in the following order:

to the "Selected Disks" Disk Selection window) is assigned as the primary

naviseccli -h cache -fast -create -disks ... -mode rw -rtype r1