Re: Adding QCOW2 reading/writing support

[Hannes Reinecke <hare@suse.de>]

On 4/17/19 1:32 PM, Manuel Bentele wrote:
> Hi,
> 
> On 17.04.19 03:35, Ming Lei wrote:
>> Hi,
>>
>> On Wed, Apr 17, 2019 at 5:33 AM Manuel Bentele <manuel-bentele@web.de> wrote:
>>> Hi everyone
>>>
>>> I'm going to implement an in-kernel reading of QCOW2 images.
>>> In the project, I only need the reading of QCOW2 images, but it's
>>> essential to make thoughts for the implementation of the writing, too.
>>> One of the difficulties seems to be the support of making an image
>>> sparse (resizing the disk image).
>> Could you describe this requirement in a bit more detail? Especially why
>> do you want to read/write QCOW2 in kernel?
> 
> Yes, of course. The implementation of reading a QCOW2 disk image
> in-kernel is required for an already existing system in the university
> environment.
> At the moment, the Linux kernel, initramfs, etc. for each client in the
> system is loaded via PXE boot and then the block device with the default
> file system is included with the help of a modified nbd version, called
> dnbd (distributed nbd).
> Due to the fact that the data on the default file system is only for non
> persistent one-time provision of a client, read access is sufficient.
> The user related data is stored on a network storage, as mostly done in
> large scale infrastructures.
> 
> Now, the goal is to minimize the network usage and avoid nbd.
> Furthermore, fixed configured and packed boot images should be avoided.
> Therefore, the advantage of the sparse and compression functionality of
> QCOW2 should be used.
> A workaround for that problem could be the local usage of nbd to include
> the QCOW2 disk image as block device, but it involves a lot of
> interaction between user and kernel space and thus an decreasing
> performance. That leads to the motivation to implement the reading of
> QCOW2 disk images directly in the kernel and aim for an merge into the
> mainline kernel source to avoid out-of-kernel-tree maintenance.
> 
> If you have any questions related to the described use case or if you
> require more information, please let me know.
> Thanks for your help.
> 
cramfs?
Or btrfs with compression enabled?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                              +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)