On 17.04.19 13:58, Hannes Reinecke wrote: > On 4/16/19 11:30 PM, Manuel Bentele 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). >> >> Now, I want to ask you for advice: What is the best approach to achieve >> this? >> >> * Implement the reading/writing in the device mapper? >> * Extend the loop device? >> * Create a new subsystem for the processing of sparse devices or >> images? >> >> Or do you have any other idea? >> > I'm not sure if that would be met with universal acclaim; file formats > are regarded as userland policies, and shouldn't be handled in the > kernel at all. > Have you looked at fuse? > > Cheers, > > Hannes I agree with your notice that file formats should stay outside the kernel space. Fuse would be a very good approach to reach the goal, but it's only intended for file systems. But QCOW2 in general can be seen as a container or virtual disk node containing various data. Therefore, functionality like blkdev_reread_part for partition scanning or fsck is needed, but it is not available in the user space. That means, code must be translated and duplicated which is again not an appropriate solution. I have seen, that the tool vmware-mount for the VMDK file format is based on fuse and supports all the mentioned block device functionality. I was wondering how they achieved that but I don't want to know how much code was duplicated. If you have an idea to solve the opposition for file formats that are acting as a container or virtual disk node for various data, please let me know. Regards, Manuel
