On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote: > On 01.10.23 22:46, Denis V. Lunev wrote: > > Can you please not top-post. This makes the discussion complex. This > > approach is followed in this mailing list and in other similar lists > > like LKML. > > > > On 10/1/23 19:08, Mike Maslenkin wrote: > > > I thought about "conv=notrunc", but my main concern is changed virtual > > > disk metadata. > > > It depends on how qemu-img used. > > > May be I followed to wrong pattern, but pros and cons of adding "conv" > > > parameter was not in my mind in scope of the first patch version. > > > I see 4 obvious ways of using `qemu-img dd`: > > > 1. Copy virtual disk data between images of same format. I think disk > > > geometry must be preserved in this case. > > > 2. Copy virtual disk data between different formats. It is a valid > > > pattern? May be `qemu-img convert` should to be used instead? > > > 3. Merge snapshots to specified disk image, i.e read current state and > > > write it to new disk image. > > > 4. Copy virtual disk data to raw binary file. Actually this patch > > > breaks 'dd' behavior for this case when source image is less (in terms > > > of logical blocks) than existed raw binary file. > > > May be for this case condition can be improved to smth like > > > if (strcmp(fmt, "raw") || !g_file_test(out.filename, > > > G_FILE_TEST_EXISTS)) . And parameter "conv=notrunc" may be implemented > > > additionally for this case. > > My personal opinion is that qemu dd when you will need to > > extract the SOME data from the original image and process > > it further. Thus I use it to copy some data into raw binary > > file. My next goal here would add ability to put data into > > stdout that would be beneficial for. Though this is out of the > > equation at the moment. > > > > Though, speaking about the approach, I would say that the > > patch changes current behavior which is not totally buggy > > under a matter of this or that taste. It should be noted that > > we are here in Linux world, not in the Mac world where we > > were in position to avoid options and selections. > > > > Thus my opinion that original behavior is to be preserved > > as somebody is relying on it. The option you are proposing > > seems valuable to me also and thus the switch is to be added. > > The switch is well-defined in the original 'dd' world thus > > either conv= option would be good, either nocreat or notrunc. > > For me 'nocreat' seems more natural. > > > > Anyway, the last word here belongs to either Hanna or Kevin ;) > > Personally, and honestly, I see no actual use for qemu-img dd at all, > because we’re trying to mimic a subset of an interface of a rather complex > program that has been designed to do what it does. We can only fail at > that. Personally, whenever I need dd functionality, I use > qemu-storage-daemon’s fuse export, and then use the actual dd program on > top. Alternatively, qemu-img convert is our native interface; > unfortunately, its feature set is lacking when compared to qemu-img dd, but > I think it would be better to improve that rather than working on qemu-img > dd.
Is there a clear view of what gaps exist in 'qemu-img convert', and more importantly, how much work is it to close the gaps, such that 'dd' could potentially be deprecated & eventually removed ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
