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@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? 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@xxxxxxxxxxxxxxxxx/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
