Support PVCs smaller than 1GB

[suleymanakbas91]

Hi,

On small edge devices with limited storage, there is a need of creating PVCs with smaller values than 1GB. Currently. TopoLVM rounds up smaller values to 1GB so this is not possible. We'd like to make this possible if there is a feasible solution. I see that the size is referred to as size_gb in the API. I was wondering if we could introduce a new field called size_mb to optionally allow the usage of values smaller than 1GB. What do you think about it? Is there any aspect we would need to think about that could make the work challenging? Thanks in advance for your comments!

[satoru-takeuchi]

Unfortunately, we have no plan to support volumes smaller than 1 GiB. TopoLVM was created for server workload. In this case, the smallest size, 1 GiB, is reasonable. In addition, the current implementation depends on this limitation very much we hesitate to change this logic to avoid regressions.

[suleymanakbas91]

Many thanks for your answer, @satoru-takeuchi! We have many edge customers who are interested in this feature, so we'd love to contribute and make additional use cases possible for TopoLVM. That's why we'd like to understand the underlying limitations more. Would you mind elaborating on where you would expect the regressions to happen and what the mentioned dependencies on the current implementation are? So, we could evaluate how we could possibly proceed further on this. I'd be willing to put together a POC. 🙂

[satoru-takeuchi]

@suleymanakbas91

we'd love to contribute and make additional use cases possible for TopoLVM.

Thank you very much.

Would you mind elaborating on where you would expect the regressions to happen and what the mentioned dependencies on the current implementation are?

Here are what I am concerned about at this moment.

• topolvm-scheduler's scoring logic assumes the minimum volume size is 1GiB. At least we should keep the current behavior for >= 1GiB volumes.
• lvmd protocol should be extended to support < 1GiB volumes. Currently, the field name meaning volume size is size_gb and the unit of size is GiB. We should support both size_gb field and the new field (possibly size_mb?).
• There are many bit shifts like ">> 30" and "<< 30" which assumes the unit of all volumes is GiB. Possibly, there are many similar hard-coded logics.

So, we could evaluate how we could possibly proceed further on this. I'd be willing to put together a POC.

After considering the above-mentioned concerns, could you send a design proposal?

[jakobmoellerdev]

Hi @satoru-takeuchi

In alignment with @suleymanakbas91, we will start preparing a design proposal for getting rid of the issues above.

Priorities:

• Ensuring backwards-compatibility with schedulers and legacy bitshifts
• Discovering all places with hardcoded bitshifts and transitioniing them to a more modular and sizable approach

Even though it will be quite the effort / code-change we are confident to be able to pull that off.

We will let you know once we have something ready here and in the corresponding PR.

[jakobmoellerdev]

@satoru-takeuchi I've opened #754 as per this discussion. Please take an extra careful look at the proposed changes to the scheduler extension.