Hi Bart
Thanks for your quick reply.
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.
Hi Manuel,
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?
[...]
Regards,
Manuel
[1] https://www.spinics.net/lists/linux-block/msg39538.html
[2] Francesc Zacarias Ribot: QLOOP Linux driver to mount QCOW2 virtual
disks; June 23, 2010;
https://upcommons.upc.edu/bitstream/handle/2099.1/9619/65757.pdf
