Modify Disk/Region management to use RegionSets

[smklein]

The current implementation of Disks, as of #511 , assumes that each disk is comprised of a single RegionSet.

Context: #511 (comment)

This artificially limits the number of regions contained within a disk to "three", which is the redundancy threshold.

In reality, disks may be comprised of multiple RegionSets, such that a larger quantity of regions are responsible.

This issue tracks the following:

• RegionSets will need to identify which sub-portion of the user volume they are responsible for managing.
• Depending on how many RegionSets may comprise a disk, we may need to start integrating pagination APIs into region access.

[jmpesp]

Is this still relevant, with the Volume work that's happened since?

[smklein]

I'm not 100% sure, but I think so? In the comment that preceded this issue, it was mentioned that a single volume could contain multiple region sets. Is that still true today? Could a volume be allocated with:

• LBA [0, N) on a set of 3 regions (from datasets 1, 2, 3)
• LBA [N, M) on a set of 3 regions (from datasets 4, 5, 6)

?

[jmpesp]

Yes, and it definitely will :).

I think this issue should be closed though. Volumes track which regions are mapped to which disks, we don't need to introduce a new RegionSet primitive.

The only question now is whether or not to paginate listing regions, but are we going to have pagination for what I currently understand is an internal-only call?