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
signature.asc
Description: PGP signature