It's very difficult.  There is some hidden data in CLI but even that won't really tell you where the LUN is sitting entirely.  Over time, all LUNs will end up all over the Pool so IO will balance to some degree but if the LUN itself was created when the pool had a small number of disks, then it will be bound to those disks as far as performance.  In VNX OE v.32, the 1GB slices are rebalanced automatically when new disks are added to the pool.  And if the VNX has the FASTVP license installed, the slices are monitored and rebalanced based on IO pattern as well (within the same tier, in addition to up and down tiers).  Unfortunately this is not the case for VNX OE v.31 and CX4 FLARE.  The recommendations for growing pools has been to start with some reasonable number of disks (15,20,30, etc) and grow in the same increments each time.  That way new LUNs will have about the same perceived performance as existing LUNs after pool expansion.  FASTCache can overcome much of the variability of performance for pool LUNs by accelerating reads and writes to busy blocks.
Hi this is a query about storage pool history to try and profile expected theoretical IO.  Background,  I understand that flare attempts to allocate disks in blocks of 5 and that therefore depending on history of a storage pool, the number of spindles data is on depends on the history of the storage pool. An example may show my understanding here.  So we allocate a raid 5 storage pool with 5 disks. In this case there is a fairly straight mapping between the storage pool and the private raid group within this. If we allocate say 10 GB ( Lets call this LUN A ). Then data is striped across 5 disks.  So now we expand the storage pool by 5 disks. Existing data is not restriped. If we allocate a second LUN ( Lets call this LUN B ) with 10 GB, data in allocated in segments of 1 GB so is striped across 10 disks.   So in calculating performance, ignoring fast for a moment,  LUN A performance is 5 x disk IOPS, with write penelty of 4. LUN B performans is 10 x disk IOPS, with write penelty of 4.  So if the above understanding is correct, we need to know the layout of the 1 GB segments to get an understanding of theoretical IOPS as simply saying its a 10 disk storage pool is misleading.  So my questions are;  1. Is the above simplistic understanding correct ? 2.. If it is correct, is there a way of knowing the segment layout to calculate the theoretical IOPs for a LUN ? 3. I have deliberatly left out FAST, as I do not know how to model this, and thoughts ? i.e. if I have a pool with 3 different disk performance characteristics, can I model what to expect in terms of performance ?
storage pool history query