Overview:
Some users have expresed confusion over the effect of various VDO format parameters or misunderstood the on-disk size requirements of various configurations. (See linked github issues.) LVM also runs vdoformat multiple time to try to measure the actual space used by various configuration parameters. We should create a tool that can do these calculation and make these user questions easier to answer.

This is somewhat motivated by the proposed vdoformat changes (VDOSTORY-292) since the current way to do these calculations is by running vdoformat. However, even now, vdoformat is not designed for that purpose and a more focused tool would likely be more effective.

Requirements:
Be able to answer (or help answer) such questions as:

• Given physical storage size X, and slab size Y, how much space will be available for data storage (plus block map)? How much space will be unused? (Caller can easily compute the minimum amount that needs to be added to allocate another slab.)
• For logical size X, how much space will be consumed by a fully allocated block map tree? And how much RAM? (An approximate ratio is easy to give for VDO generally but for a specific logical size we can compute it precisely. The block map size might also be used to choose a block map cache size when starting the device.)
• For physical storage size X, slab size Y, and logical size Z, how much space will be available for data storage once the block map tree is fully allocated?
• For a given index size and sparseness, what’s the size of the dedupe window (or dense and sparse windows both) the index can remember? (Okay to just document? I think that’s a simple fixed ratio. But how do duplication and copied index entries affect how much unique data can be remembered?) The dedupe window may necessarily be approximate; round down. May need to account for thread counts.
• For given format parameters X, Y, Z, how much physical space will be required? And how much RAM?
  Optional:
• For physical storage size X, slab size Y, and expected space savings rate Z, how much logical space should we allocate to correspond to the physical space that will be available? (Computable from above?)
• For slab size X, what’re the smallest and largest physical sizes that can be supported? For physical size X, what’re the smallest and largest slab sizes that can be supported? (Must factor in index and other non-slab space. Maybe just generate a table of physical size ranges for all slab sizes?)

For handy programmatic use, a json/yaml output option in addition to human-friendly is desirable.

Also, we don't get it from vdoformat+vdolistmetadata, but perhaps add:

• How much RAM will this configuration need?

Unlike the format questions, this could change with newer versions of the driver.

Design:
Who can we ask for more use cases?
Zdenek/lvm:
Dennis/stratis:
Review github for user questions, to address those questions.

What are the use cases for this:
Sizing for lvm? What question(s) are lvm answering?

Parameters that format cares about:
logical size
physical size
index memory size
index sparse flag
slab bits/size
thread counts

Output Format:
YAML may be the simplest format.
Output must work without error within the constraints.
Be clear about what requirements are strictly calculated, and which are advisory.

Tasks: 10 IEH
Write the tool (deterministic calculations): 4 IEH
Write the tool (advisory calculations): 4 IEH
Tests : 2 IEH