GNU bug report logs - #6004
[libvirt] [PATCH 3/4] Fix QEMU save/restore with block devices

Previous Next

Package: coreutils;

Reported by: Eric Blake <eblake <at> redhat.com>

Date: Thu, 22 Apr 2010 14:40:02 UTC

Severity: normal

Tags: notabug, patch

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Daniel P. Berrange" <berrange <at> redhat.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: libvir-list <at> redhat.com, bug-coreutils <bug-coreutils <at> gnu.org>
Subject: Re: [libvirt] [PATCH 3/4] Fix QEMU save/restore with block devices
Date: Thu, 22 Apr 2010 15:53:37 +0100
On Thu, Apr 22, 2010 at 08:39:26AM -0600, Eric Blake wrote:
> [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).

Yep, just looked at status=noxfer, but there's not much point in it since
it still prints other stats unconditionally.

> 
> 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

It really isn't worth the bother. A couple of lines of dd output in the
logfile is no harm to anything.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|





This bug report was last modified 12 years and 62 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.