Paul,
I assume you are concerned with the number of volumes, not necessarily the backend storage location. OnBase will continue to work properly when you roll over 9,999 volumes. If the number of volumes in a disk group is of concern, you might choose to change the size of the volume based on the fill rate of that disk group volume.
For example, if you have 4 GB volumes that are promoting every couple days, you might be able to change the size of the volumes so fewer are created over time. Volume size could have an impact on other things like; backups, UNC path assignments, and frequency of deletions (if you are deleting volumes in your solution) among other things. You have to ask, if we increased the size of the OnBase volume, what might be impacted in terms of backups and maintenance outside of the OnBase solution. You want to, “right size” the volumes – not just arbitrarily pick a size that becomes unmanageable for some reason.
If you have document retention configured, files are likely being deleted from volumes over time. This can lead to empty volumes which is not a problem in OnBase. If you use a backend storage system that uses thin provisioning, the storage space will actually be reclaimed once files are deleted. The “logical” OnBase volume will remain but will not consume any space on storage once all of the files in the volume are deleted via retention.
Hope this helps. If I haven’t answered your question, is there a specific problem you are trying to solve?
