On 18.04.19 03:05, Ming Lei wrote: > On Thu, Apr 18, 2019 at 5:04 AM Manuel Bentele <manuel-bentele@xxxxxx> wrote: >> On 17.04.19 14:16, Hannes Reinecke wrote: >>> 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@xxxxxx> 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 >> Thanks for your simple idea to choose cramfs or btrfs with compression >> enabled. >> I will suggest that as alternative at the next project meeting. > Or vdo which provides compression in block device level: > > https://github.com/dm-vdo/vdo Thanks for your hint. I will take a look at it. Regards, Manuel
