Linux-Block Archive on
 help / color / Atom feed
From: Manuel Bentele <>
To: Hannes Reinecke <>
Subject: Re: Adding QCOW2 reading/writing support
Date: Wed, 17 Apr 2019 23:53:25 +0200
Message-ID: <> (raw)
In-Reply-To: <>

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.


  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16 21:30 Manuel Bentele
2019-04-17  1:35 ` Ming Lei
2019-04-17 11:32   ` Manuel Bentele
2019-04-17 12:16     ` Hannes Reinecke
2019-04-17 21:04       ` Manuel Bentele
2019-04-18  1:05         ` Ming Lei
2019-04-18 10:02           ` Manuel Bentele
2019-05-14  8:56             ` Manuel Bentele
2019-04-17 11:58 ` Hannes Reinecke
2019-04-17 21:53   ` Manuel Bentele [this message]
2019-05-14 14:28     ` Roman Penyaev
2019-05-20 13:05       ` Manuel Bentele

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Block Archive on

Archives are clonable:
	git clone --mirror linux-block/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-block linux-block/ \
	public-inbox-index linux-block

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox