I've got an extra question, if you add an extra 5 disks to a existing 5 disk R5 pool. Will it create an extra 4+1R5 and attach that to the pool or will it create a 9+1R5 pool?

4+1R5

Avi wrote: FLARE will not re-distribute the existing data into the new drives, but the algorithm makes sure that new data will be placed in such a manner that all the drives get equally used. So, you will have more storage chunks getting allocated from the new drives after they are added.

That's not what I wanted to hear. My expectation was that it would work just as MetaLUN striped expansion would, and restripe data across all spindles. In a sense, you need to be careful about the initial design of the storage pool, otherwise you could wind up with a hot area in the pool.

With the addition of FAST, will it at all redistribute data across the same tier of disk in an attempt to redistribute hot blocks?

I guess the possible "answer" would be to add additional disks to the pool, then do a thin-to-thin LUN migration. My assumption then being that the new LUN would be more evenly distributed across all spindles.

Jeff

FLARE will not re-distribute the existing data into the new drives, but the algorithm makes sure that new data will be placed in such a manner that all the drives get equally used. So, you will have more storage chunks getting allocated from the new drives after they are added. 

Avi wrote: FLARE will not re-distribute the existing data into the new drives, but the algorithm makes sure that new data will be placed in such a manner that all the drives get equally used. So, you will have more storage chunks getting allocated from the new drives after they are added.

that's is disappointing to hear indeed. I was expecting the same functionality as on VMAX where once new devices are added to the pool, existing data in the pool gets rebalanced onto the new drives, thus giving you more performance and avoid creating hot spots.

Very disappointing indeed. You'd expect when you need more performance, you only need to add a few extra drives and everything is ok again, but I guess that's not the case then.

RFE ? (=request for enhancement)

Message was edited by: RRR

what are supposed to see ? Thick LUNs within pool are better for performance application ?

You might also want to review the latest Virtual Provisioning White Paper:

White Paper EMC CLARiiON Virtual Provisioning  - Applied Technology.pdf

See the Executive Summary, second paragraph and page 15 for usage of thin LUNs

glen

Thin LUNs are not appropriate for performance sensitive applications.

glen

ok, but even with thick LUNs, if i add more space to the pool ..data is not re-striped. So if i have a thick LUN that needs more IOPS, adding more devices to the pool will not help. Maybe Clariion developers should have picked over VMAX engineer's shoulder..to see how they are implementing pool functionality.