Storage Allocation Units (SAU) is Datacores "blocksize" when formatting a pool. At creation time of the pool you have to define the size of each SAU, ranging from 4MB to 1024MB with a default size of 128MB. With a SAU of 128MB, you can create pools with ~1PB of size. If you want to have the ability to add more than 1PB of diskspace to a pool, you have to take larger SAU sizes.
The SAU size can only be set at pool creation time. There is no way to change it afterwards.
Datacore recommends a SAU of 128MB with SSY-V. In former version like SANsymphony7 or SANmelody, the recommendation was to lower the SAU size for virtualized environments because with a lower SAU size, there will be smaller data chunks.
For example: if you have a SAU of 128MB and a data packet of 1GB in size, this data packet will be split in eight subpackets, spread across eight disks in your pool. If you have more disks in your pool, this 1GB packet will not use more than these eight disks.
If you lower the SAU to 8MB this would result in 128 data packets spread across all your disks. This way you would use all disks and the chance to profit from this disk layout is much higher than with a higher SAU.
This example is a bit unworldly but can give you a reason why formerly a lower SAU size was practically used.
With these information in mind we can calculate what maximum pool size each SAU increment supports. Unfortunately you have to calculate yourself because there is no such information officially released by Datacore.
The following table shows each combination based on the fact that 128MB SAU supports 1PB pool size.
|SAU size||Maximum pool size|
The problem with this table is, that it is not correct. Assuming 8MB SAU size, you should have the ability to create disk pools with ~64TB of capacity.
We recently tried to upgrade a pool with initial ~31TB with additional 4TB of space. As soon as we try to add a single drive to this pool, the GUI throws an error that the disk can't be added.
This is rather annoying than problematic but the second reaction of that task is that the whole pool goes offline and can't be accessed anymore.
This is really something I haven't expected. It might be okay to deny the disk addition because of some non-documented limit but why does the pool go offline?
Fortunately you can bring the pool back online by simply rescanning the storage HBAs but it should never happen that a pool goes down just becasue of a simple "add disk" action.
We tried this procedure with SANsymphony 7 and SANsymphony-V8/9 and always got the same errors and pool problems.
Calling Datacore support and asking them for help didn't do anything so for the moment the only recommendation from the support guys is to delete the pool, recreate it with a SAU of 128MB and rebuild all mirrors.
Funny thing with 31TB of data......