Am 13.12.2018 um 15:23 hat Eric Blake geschrieben: > On 12/13/18 8:05 AM, Kevin Wolf wrote: > > Am 13.12.2018 um 11:47 hat Daniel P. Berrangé geschrieben: > > > On Thu, Dec 13, 2018 at 01:52:29AM +0200, Nir Soffer wrote: > > > > On Thu, Dec 13, 2018 at 12:13 AM Eric Blake <ebl...@redhat.com> wrote: > > > > > > > > > > When a qemu-io command fails, it's best if the failure message > > > > > goes to stderr rather than stdout. > > > > > > > > This makes sense, but it will break users like this: > > > > > > > > https://github.com/oVirt/vdsm/blob/a2836b1d58ffaa0f48cc9c814b6002161a81f044/tests/storage/qemuio.py#L45 > > > > > > > > We need a way to detect qemu-io verification failures, maybe a special > > > > exit code? > > > > > > > > 0 - verification succeeded > > > > 1 - verification failed > > > > 2 - other error (e.g no such file) > > > > > > This makes sense. We should *never* expect applications to parse the > > > messages on stdout/err, because we reserve the right to change text > > > arbitrarily at any time. So we need to use exit status IMHO. > > > > qemu-io processes more than just a single command. What would the exit > > code be if one of the commands succeeds, one gets an I/O error, and the > > third one succeeds for I/O, but fails pattern verification? > > > > The things is, qemu-io was never meant to be used by other > > applications that need to process the results, it's a tool for testing > > and debugging. If we had meant it to be used by other programs, we would > > have given it a machine-friendly interface. > > > > The machine-friendly interface to the QEMU block layer is qemu-nbd. > > > > > > Or, if qemu-io had a way to read data and write it to stdout, we could > > > > compare the data and avoid the need for special exit code. > > > > > > That should be trivial to do, and quite desirable too IMHO - libvirt would > > > in fact quite like such a feature, as it would let us support format > > > conversions when using our upload/download APIs, without having to create > > > intermediate files. Alternatively 'qemu-img convert' could allow for > > > /dev/stdin and /dev/stdout as raw files, but that looks considerably > > > harder to implement. > > > > > > For your usecase that feels rather inefficient as you're introducing > > > multiple data copies, which will be bad for large images. Much better > > > if we just make qemu-io set good exit codes. > > > > 'read -v' produces a hex dump on stdout, but you still need to separate > > it from the other output and then parse the hexdump. > > > > The human interface of qemu-io is honestly just not the right tool for > > the job, and adding one-off tweaks to make it a little bit less horrible > > to use for machines isn't the right approach because it's still not a > > proper machine protocol. > > I actually agree with that sentiment - qemu-io is NOT a program where we > promise backwards compatibility (we're not going to break it without reason, > because we DO have to keep iotests running, but outside of iotests, we are > less concerned if other uses break). > > But it DOES sound like teaching 'qemu-img convert' to optionally convert > only a subset of a file may be useful (I already tried once to make > 'qemu-img dd' smarter, and the conclusion at the time is that it would be > better to just make qemu-img dd be syntactic sugar for a full-featured > qemu-img convert, which means making convert take an offset and range limit > to the source, as well as a separate offset into the destination, for easily > extracting portions of one file into portions of another). And I also agree > that qemu-nbd already has offset and range support.
Can't you actually already achieve this with --image-opts and a raw filter that has the offset/size options set? It's not as nice as with a separate option, but it should do the job. Kevin
