Am 05.02.21 um 09:18 schrieb Max Reitz: > On 04.02.21 21:09, Peter Lieven wrote: >> Am 02.02.21 um 16:51 schrieb Eric Blake: >>> On 1/28/21 8:07 AM, Peter Lieven wrote: >>>> Signed-off-by: Peter Lieven <p...@kamp.de> >>> Your commit message says 'what', but not 'why'. Generally, the one-line >>> 'what' works well as the subject line, but you want the commit body to >>> give an argument why your patch should be applied, rather than blank. >>> >>> Here's the last time we tried to improve qemu-img dd: >>> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg02618.html >> >> >> I was not aware of that story. My use case is that I want to be >> >> able to "patch" an image that Qemu is able to handle by overwriting >> >> certain sectors. And I especially do not want to "mount" that image >> >> via qemu-nbd because I might not trust it. I totally want to avoid that the >> host >> >> system tries to analyse that image in terms of scanning the bootsector, >> partprobe, >> >> lvm etc. pp. > > qemu will have FUSE exporting as of 6.0 (didn’t quite make it into 5.2), so > you can do something like this: > > $ qemu-storage-daemon \ > --blockdev node-name=export,driver=qcow2,\ > file.driver=file,file.filename=image.qcow2 \ > --export fuse,id=fuse,node-name=export,mountpoint=image.qcow2 > > This exports the image on image.qcow2 (i.e., on itself) and so by accessing > the image file you then get raw access to its contents (so you can use system > tools like dd). > > Doesn’t require root rights, and shouldn’t make the kernel scan anything, > because it’s exported as just a regular file.
Okay, but that is still more housekeeping than just invoking a single command. Would it be an option to extend qemu-io to write data at a certain offset which it reads from STDIN? Peter
