[libvirt] [PATCH 3/4] Fix QEMU save/restore with block devices

Eric Blake eblake at redhat.com
Thu Apr 22 14:39:26 UTC 2010


[adding bug-coreutils]

On 04/22/2010 04:37 AM, Daniel P. Berrange wrote:
>>> -    if (virAsprintf(&dest, "exec:%s >>%s 2>/dev/null", argstr, safe_target) < 0) {
>>> +    if (virAsprintf(&dest, "exec:%s | dd of=%s seek=%llub",
>>> +                    argstr, safe_target, offset) < 0) {
>>
>> Don't you still need to silence stderr, particularly since dd writes to
>> stderr even on success? (2 instances)
> 
> I didn't want to silence stderr, because I want it to end up in the QEMU
> logfile if anything goes wrong. So i really need  a way to make dd keep
> quiet on success, rather than throwing away stderr

Coreutils comes with an extension 'dd status=noxfer' which silences some
(but not all) output to stderr, but you'd have to test whether you are
targetting coreutils' dd (if dd comes from somewhere else, like busybox,
you'll cause a syntax error that prevents dd from doing anything at all).

There was a patch submitted to coreutils [1] that would add
status=noinfo, but it is currently held up by copyright status and lack
of documentation.  Maybe I should revive that patch (or rather, write it
from scratch, to avoid copyright taint).  But even so, you are still up
against the issue of testing whether you are targetting new-enough dd.

[1] http://lists.gnu.org/archive/html/bug-coreutils/2010-02/msg00161.html

About the best you can portably do, then, is capture stderr, then check
the exit status of dd; if the exit status is 0, discard the captured
stderr; otherwise, pass the stderr on to the logfile:

foo | dd of=a seek=$n 2>b; st=$?; if test $st != 0; then cat b >&2; \
  fi && rm -f b && exit $st

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100422/b6e2b061/attachment-0001.sig>


More information about the libvir-list mailing list