On 8/24/19 2:14 AM, Manuel Bentele wrote:
On 8/24/19 5:37 AM, Bart Van Assche wrote:
On 8/23/19 3:56 PM, development@xxxxxxxxxxxxxxxxx wrote:
During the discussion, it turned out that the implementation as device
mapper target is not applicable. The device mapper stacks different
functionality such as compression or encryption on multiple block device
layers whereas an implementation for the QCOW2 container format provides
these functionalities on one block device layer.
Is there a more detailed discussion available of this subject?
>
No, the only discussion is the referenced one [1]. But there was a
similar discussion in the master's thesis of Francesc Zacarias Ribot
[2]. Unfortunately, I found no attempt on the mailing list that proposes
his solution.
Are you familiar with the dm-crypt driver?
>
I don't know the specific implementation details, but I use this driver
personally and I like it. Do you want to propose that only the storage
aspect of the QCOW2 container format should be used and all other
functionality inside the container should be provided by available
device mapper targets?
(+Mike Snitzer)
Hmm, I haven't found any reference to the device mapper in the document
written by Francesc. Maybe that means that I overlooked something?
I referred to the dm-crypt driver because I think that's an example that
shows that QCOW2 file format support could be implemented using the
device mapper framework.
Mike, do you perhaps want to comment on what the most appropriate way is
to implement such functionality? The entire patch series is available at
https://lore.kernel.org/linux-block/86279379-32ac-15e9-2f91-68ce9c94cfbf@xxxxxxxxxxxxxxxxx/T/#t.
Thanks,
Bart.
