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

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

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. ;-)

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

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]