4 Ruthenium

## Re: FAST VP

Sorry, based on the order of the automatic emails received, I missed this one.

So as for the pool LUN overhead, that is the generally accepted formula; however, it is an estimate and starts deviating further from the 2% as the LUN's get larger.  You are doing the math correctly.  Based on what you are actually seeing (147GB vs 111GB), this works out closer to 2.7%.  So as you demonstrated, the overhead seems to  range from 2 - 3% depending on how large the LUN.  I'm assuming that a 16TB LUN which is the largest possible single LUN on a VNX currently, we would find it to be closer to 3% (maybe slightly larger)?  You have piqued my curiosity now and I may do some testing.

As for leaving unallocated space in a FAST VP configuration, it really comes down to keeping the math simple when you are sizing all the available capacity (up to the recommended free space) as in the case of filestorage where the pool is dedicated upfront.  As you've already demonstrated, it really would make it difficult to size and would almost be trial and error if your goal was to align perfectly to 5 or 10% (which isn't absolutely necessary).  Therefore when you are going to allocate all of the space up front such as in the case of filestorage, once you calculate the number of LUNs per the bp mentioned above, simply divide that into 95% of the total capacity.  This is per an internal powerpoint that was brought to my attention recently and again, the goal is to keep the math simple.  Keep in mind, it isn't wrong if you also calculated the overhead first as I proposed originally.

On the other hand, with block storage, it is a bit different.  Unlike filestorage (block LUNs presented to the data movers) where you are allocating it entirely upfront, with block storage you are typically building up and adding LUNs over time.  Therefore, you will have visibility to the allocated capacity (which already includes the overhead) and can stop at 90% of the total capacity of the pool.  Does this make sense?

As for the comment regarding the placeholder LUN, as I noted, with VNX OE for Block 31 where a thick LUN only reserved the space but didn't actually allocate it, then I can see this as a strategy to leave 10% unallocated space that can be used for leaving room for optimal tiering.  You qualified it by a third level EMC engineer so I also don't want to contradict him/her.  However, since most have moved to Inyo (and in consideration of those that read this later), I personally wouldn't rely on this strategy.  As a reminder, with Inyo, thick LUNs both reserve the space and fully allocate the LUN so those slices aren't available for tiering.