8.3 docs on "Physical Storage" only refers to Flash Pools when talking about using Storage Pools on SSDs. Is there some reason the Storage Pool allocations can't/shouldn't be used to create all-SSD aggregates as well? Nos supported? Not BP?
Storage pools partition the SSDs differently. In a pure SSD aggregate they are either unpartitioned, or root/data partitioned if the platform was initialized with ADP. Storage Pool's partition them into 4 slices so you can apply cache to more aggregates with fewer SSDs.
My core question is, how disk-like are the four SSD partitions that get created when you create Storage Pools? Can I make a pure SSD aggregate out of them, or is their use limited to adding cache space to Flash Pools?
What I wanted to explore was to see if we can apply the parity amortization advantage of Storage Pools beyond Flash Pools.
Now the usual aggr creation method fails, because I don't have enough spare SSD left:
crshtst1::storage pool*> aggr create -aggregate ssd1 -diskcount 5 -disktype ssD
[Job 21] Job is queued: Create ssd1.
Error: command failed: [Job 21] Job failed: Failed to create aggregate "ssd1"
on "crshtst1-01". Reason: 5 disks needed from one pool, but not enough
matching disks are available in either pool.
crshtst1::storage disk partition*> aggr create -aggregate test1 -partitionlist VMw-1.16.P1,VMw-1.17.P1,VMw-1.18.P1,VMw-1.19.P1,VMw-1.20.P1
[Job 22] Job is queued: Create test1.
Error: command failed: [Job 22] Job failed: Failed to create aggregate "test1"
on "crshtst1-01". Reason: Disk "VMw-1.16.P1" is part of a storage pool.
Please use the 'aggregate add' command with the '-storage-pool' option
to add capacity from a storage pool to an aggregate.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.