Re: [PATCH 0/5] block: loop: add file format subsystem and QCOW2 file format driver

[Bart Van Assche <bvanassche@acm.org>]

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@manuel-bentele.de 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@manuel-bentele.de/T/#t.

Thanks,

Bart.