On 5/4/26 12:01 PM, Mikulas Patocka wrote:
On Wed, 29 Apr 2026, Matthew Sakai wrote:
On 4/29/26 11:24 AM, Mikulas Patocka wrote:
Hi
I think the best way how to support it would be to modify the VDO target
to use the asynchronous compression API (so that it could use arbitrary
algorithms). Then, the support for IAA could be plugged in easily with
little or no extra code.
I agree that this is the right approach, but supporting arbitrary compression
algorithms will require some significant changes on its own. dm-vdo currently
has nowhere to store information about what algorithm is used for which
blocks, so it would require reworking the metadata. (We would probably store
You can store the algorithm in the superblock and use it for all blocks on
the device. This would be not as flexible as per-block algorithm
specification, but it should be relatively easy to implement - and it
would allow you to evaluate whether different algorithms improve
performance or compression ratio.
We could do that, certainly. It means picking the compression algorithm
at format time, which also means no existing vdo volumes could take
advantage of it. But we'd still need an upgrade for existing volumes to
handle the new superblock field. I think managing the compression
algorithm per-block is not that much more work, especially since I've
already written much of it.
the extra compression information in the compression block header.) This
metadata rework in turn will require some effort to make sure we can continue
to support existing users who will want to continue to use dm-vdo volumes in
the current format.
Mikulas
