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

[Manuel Bentele <development@manuel-bentele.de>]

On 8/24/19 6:04 PM, Bart Van Assche wrote:
> 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?
Oh sorry, you're right. I meant this in general for the topic 'QCOW2 in
the kernel space'.

> 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.
Okay, now I get it :)

> Mike, do you perhaps want to comment on what the most appropriate way
> is to implement such functionality?

To implement the QCOW2 format or other sparse container formats
correctly, the implementation must be able to ...
  - extend the capacity of the mapped block device
  - shrink the capacity of the mapped block device
  - rescan the paritions of the mapped block device

Are all three functionalities feasible using the device mapper framework?

> The entire patch series is available at
> https://lore.kernel.org/linux-block/86279379-32ac-15e9-2f91-68ce9c94cfbf@manuel-bentele.de/T/#t.

Note that PATCH [1/5] is missing in this series, although I've submitted
it twice. I asked already in [1] for the reason but haven't received any
answer, yet. Therefore, I temporarily insert a link to my repository
showing the missing PATCH [1/5]:
https://github.com/bahnwaerter/linux/commit/7a78da744b4c84809ad6aa20673a2b686bafb201

Regards,
Manuel

[1] https://www.spinics.net/lists/linux-block/msg44255.html