From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuOjq-0003WQ-NP for qemu-devel@nongnu.org; Thu, 05 Nov 2015 12:54:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuOjp-0007CD-PZ for qemu-devel@nongnu.org; Thu, 05 Nov 2015 12:54:18 -0500 References: <1446663467-22485-1-git-send-email-mreitz@redhat.com> <1446663467-22485-15-git-send-email-mreitz@redhat.com> <563B8EBA.8070506@redhat.com> <563B93BD.2080805@redhat.com> <563B94A5.3030905@redhat.com> <563B9586.4020201@redhat.com> From: Paolo Bonzini Message-ID: <563B97BD.7080700@redhat.com> Date: Thu, 5 Nov 2015 18:54:05 +0100 MIME-Version: 1.0 In-Reply-To: <563B9586.4020201@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 14/15] block: Rewrite bdrv_close_all() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Max Reitz , qemu-block@nongnu.org Cc: Kevin Wolf , Alberto Garcia , qemu-devel@nongnu.org, Stefan Hajnoczi , Markus Armbruster -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/11/2015 18:44, Eric Blake wrote: >>> If you test it with all jobs, then it's okay. It's a >>> regression, but not introduced by your patch and apparently >>> nobody noticed. >>> >>> Even if nobody noticed, I wonder if this "Node 'foo' is busy" >>> kind of error deserves its own ErrorClass. Eric, what do you >>> think? > Needing a unique ErrorClass is only important if we expect a > client (libvirt) would behave differently based on that error class > (clients are not allowed to parse the error message). But what is > the scenario that we are trying to test here, rewritten in terms of > libvirt API commands? Should libvirt behave any differently > because a blockjob was running than for any other failure, if the > end result is still that libvirt can't eject or hot-unplug the disk > because of a failure? It may want to cancel the job and redo the operation. Or it may trigger an assertion failure. I don't know... that's why I asked. :) Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWO5e4AAoJEL/70l94x66DbSQH/31+AI5zFN9UtbQCMgzEKQfA EYm2gqZOQtOyaRRQI1VKOzekKTy60Y1Z1iT84PrZz7pI3PhG/qoEGG5aOeKxqjc8 tkl0DxYd4y1Mhf2Hgm4bNcswcEx5wshy0hIbqFQJUVokE0e7bx297ePw5zoTU1uY HOI0298gEHV7DA0Ux4koMi+88rIA5oPAWf3Hlxpf2A4152KXrVyh24ErELCkClCR p5EVy0urZgwscpm38GK+a2xXq8IQXRYbJZbnTxGaCLY4TAvuaEWhJ90B0mhvnNch GFKQPHMfrtR7N0b31hX4Ok2sRUKH/0/kKrjp/NpFxohNL0Rp9XS5JvQuGe+i3+s= =bl13 -----END PGP SIGNATURE-----