-
Notifications
You must be signed in to change notification settings - Fork 1
Description
The motivating example here is a scheduling system sitting on top of Lotman that wants to know something about the state of reserved disk at some point in the future. The scheduling system may want to pre-allocate dedicated storage for some point in the future for lots whose creation time hasn't been reached. When it does this, the scheduling system needs to know how much of the total disk is reserved at that future point. Right now, the only way to do that would be to fetch all the lots and do some math on their MPIs.
Instead, this could be a separate Lotman API that takes a time range and returns the sum of the various MPAs.
One nuance that I wanted to write down while it's fresh in mind is that if the goal is to create a new lot that lives for a specified duration, the available space that can be assigned as dedicated storage is total - max_i(sum_j(ded_ij)) where the i are timesteps and j are the lots that exist at timestep i.
For example, assume that the diagram below represents a system with 10GB of total storage. The beginning bar of each lot represents its creation and the ending bar represents its expiration. Furthermore, each lot is allocated 1GB of dedicated storage. Because lotA, lotB, and lotC overlap in time, the largest amount of space that could be continuously allocated to ?'s dedicated storage is 10GB - 3GB = 7GB.
Alternatively, if lotA, lotB and lotC each remained at 1GB of dedicated storage but lotD instead had 6GB dedicated, then the maximum continuous allocation we could give to ? becomes 10GB - 6GB = 4GB.
--- time --->
|---------- lotA ---------|
|----------- lotB -----------|
|--- lotC ---|
|--- lotD ---|
|----------------------- ? -------------------------|