Re: [Qemu-devel] [PATCH 2/2] qemu-img: Add dd seek= option

[Max Reitz]

On 2018-08-16 09:15, Kevin Wolf wrote:
> Am 16.08.2018 um 04:49 hat Max Reitz geschrieben:
>> On 2018-08-16 04:39, Eric Blake wrote:
>>> If convert were more powerful, I'd be fine dropping 'qemu-img dd' after
>>> a proper deprecation period.
>>
>> Technically it has those features already, with the raw block driver's
>> offset and size parameters.
> 
> In a way, yes. It requires you to precreate the target image, though,
> because --target-image-opts requires -n.
> 
> We'll probably want to fix something in this area anyway because in the
> common case, you already need those options to even precreate the image,
> and qemu-img create doesn't support open options for the protocol layer
> either (unlike blockdev-create).
> 
>>>> ((That gave me a good idea.  Actually, it's probably not such a good
>>>> idea, but I guess I'll do it in my spare time anyway.  A qemu-img fuse
>>>> might be nice which represents an image as a raw image at some mount
>>>> point.  Benefits over qemu-nbd: (1) You don't need root, (2) you don't
>>>> need to type modprobe nbd.))
>>>
>>> So the kernel->userspace translation would be happening via the FUSE
>>> interface instead of the NBD interface.  Data still bounces around just
>>> as much, but it might be a fun project.  Does fuse behave well when
>>> serving exactly one file at the mountpoint, rather than the more typical
>>> file system rooted in a directory?  NBD at least has the benefit of
>>> claiming to be a block device all along, rather than complicating the
>>> user interface with POSIX file system rules (which you'll be bending,
>>> because you are serving exactly one file instead of a system).
> 
> To make it more real, you could expose a snapshots/ subdirectory. Or
> maybe better not.
> 
>> Well, but I can just pretend my FUSE file is a block device, no?
>>
>> Also, I just discovered something really interesting: FUSE allows you to
>> specify a single file as a mountpoint.
>>
>> And you know what?  You can open the original file before you replace it
>> by the FUSE "filesystem".
>>
>> So my fun interface is going to looks like this:
>>
>> $ qemu-img fuse foo.qcow2
>>
>> And then your foo.qcow2 is a raw image until the next "fusermount -u
>> foo.qcow2"!  Isn't that fun?
> 
> Yes, sounds fun. Until you realise that I'd actually like to merge
> something like this when it exists. ;-)

Well, for reference:

https://git.xanclic.moe/XanClic/qemu/commits/branch/qemu-img-fuse

(The main issue now is that you don't see FUSE error messages,
because...  Well.  FUSE likes to fork the daemon process itself, but for
some reason that doesn't really work with qemu.  I don't really want to
investigate that, instead I rather like to declare it broken and launch
FUSE in foreground mode, and then do the forking ourselves (like
qemu-nbd does).  But then we lose all error output from FUSE, because we
have to close stderr before we get to the main loop...

(I suppose I can just look into what fuse_main() does exactly and
replicate that.  The doc says using fuse_main() is just lazy anyway. O:-P))

> For a more serious implementation, maybe it should even be a separate
> qemu-fuse rather than a qemu-img subcommand.

True.  It doesn't really fit well into qemu-img.

(To me, qemu-img is about exposing block layer features without the user
having to use qemu proper.  Exporting an image over FUSE really is not a
block layer feature.)

Max

signature.asc
Description: OpenPGP digital signature