From: Manuel Bentele <manuel-bentele@web.de>
To: Hannes Reinecke <hare@suse.de>
Cc: linux-block@vger.kernel.org
Subject: Re: Adding QCOW2 reading/writing support
Date: Wed, 17 Apr 2019 23:53:25 +0200 [thread overview]
Message-ID: <762bceb9-c66c-0a45-7d6b-e5ed0df56cbf@web.de> (raw)
In-Reply-To: <c6b31507-bb02-c886-aea6-4165606f215d@suse.de>
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
next prev parent reply other threads:[~2019-04-17 21:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 21:30 Adding QCOW2 reading/writing support 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 publicly 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=762bceb9-c66c-0a45-7d6b-e5ed0df56cbf@web.de \
--to=manuel-bentele@web.de \
--cc=hare@suse.de \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).