From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bD5be-00014Z-DJ for qemu-devel@nongnu.org; Wed, 15 Jun 2016 03:51:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bD5bZ-0000EU-6H for qemu-devel@nongnu.org; Wed, 15 Jun 2016 03:51:21 -0400 Date: Wed, 15 Jun 2016 09:51:08 +0200 From: Kevin Wolf Message-ID: <20160615075108.GB4566@noname.redhat.com> References: <1465595961-4762-1-git-send-email-jsnow@redhat.com> <905ed66e-9f55-b27f-6a98-1c2a845f3759@redhat.com> <9058ee75-0e95-a35f-4ab1-ca801baafa96@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <9058ee75-0e95-a35f-4ab1-ca801baafa96@redhat.com> Subject: Re: [Qemu-devel] [PATCH] block-backend: allow flush on devices with open tray List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: John Snow , qemu-block@nongnu.org, qemu-devel@nongnu.org --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 14.06.2016 um 18:13 hat Max Reitz geschrieben: > On 14.06.2016 17:54, John Snow wrote: > >=20 > >=20 > > On 06/14/2016 09:19 AM, Max Reitz wrote: > >> On 10.06.2016 23:59, John Snow wrote: > >>> If a device still has an attached BDS because the medium has not yet > >>> been removed, we will be unable to migrate to a new host because > >>> blk_flush will return an error for that backend. > >>> > >>> Replace the call to blk_is_available to blk_is_inserted to weaken > >>> the check and allow flushes from the backend to work, while still > >>> disallowing flushes from the frontend/device model to work. > >>> > >>> This fixes a regression present in 2.6.0 caused by the following comm= it: > >>> fe1a9cbc339bb54d20f1ca4c1e8788d16944d5cf > >>> block: Move some bdrv_*_all() functions to BB > >>> > >>> Signed-off-by: John Snow > >>> --- > >>> block/block-backend.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> I'm still not sure we shouldn't do the same for blk_{co,aio}_flush(). I > >> guess you exclude them here because you specifically want to fix the > >> issue mentioned in the commit message, but then we could just make > >> blk_flush_all() ignore an -ENOMEDIUM. > >=20 > > Yeah, I didn't investigate the full path. Just making the minimal fixes. > > Is there a concern that this may still leave certain pathways broken > > when the CDROM tray is open? > >=20 > > I don't know of any immediately without digging again. > >=20 > >> > >> I personally think we should make all blk_*flush() functions use > >> blk_is_inserted() instead of blk_is_available(). As we have discussed = on > >> IRC, there are probably not that many cases a guest can flush a medium > >> in an open tray anyway (because the main use case are read-only > >> CD-ROMs), and even if so, that wouldn't change any data, so even if the > >> guest can actually flush something on an open tray, I don't think anyo= ne > >> would complain. > >> > >> Max > >> > >=20 > > I have difficulty making pragmatic arguments when purity is at stake, > > but I've already wandered outside of my device model, so I will defer to > > your judgment. > >=20 > >>> diff --git a/block/block-backend.c b/block/block-backend.c > >>> index 34500e6..d1e875e 100644 > >>> --- a/block/block-backend.c > >>> +++ b/block/block-backend.c > >>> @@ -1122,7 +1122,7 @@ int blk_co_flush(BlockBackend *blk) > >>> =20 > >>> int blk_flush(BlockBackend *blk) > >>> { > >>> - if (!blk_is_available(blk)) { > >>> + if (!blk_is_inserted(blk)) { > >>> return -ENOMEDIUM; > >>> } > >>> =20 > >>> > >> > >> > >=20 > > Is this a NACK unless I attempt to address the wider design issue? >=20 > I just don't see a point in using blk_is_inserted() here but > blk_is_available() in the other blk_*flush() functions. If > blk_is_inserted() is correct for blk_flush(), it should be correct for > blk_co_flush() and blk_aio_flush(), too. I agree, if we can, we should keep the behaviour consistent between all interfaces types (sync/AIO/coroutine, byte-based/sector-based) for the same operation. Eric also rightfully said that we need a test cases, so a v2 would be good anyway. Kevin --UugvWAfsgieZRqgk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXYQjsAAoJEH8JsnLIjy/WWekQAKv2oYSnaFYIakgirnTGWbGM Z0R27acdeHps2J9Yr7L5IlBGJ3ZI5BM4anjbASoDbzDQq5o97EmgoG8JP+/Zynl6 6SXqSfNPaFIvHNuB6j8nQCnIlwHsetXyovIzRSC5yaho6ykGQpXXrvdQxyjkBMrG zXHZO/W9NB6gn147u+UIKAWHEIb9vQCCTZqQ4mQ4y3m8Ft0OSJoDgrsE3lk+3XbW z+ZLaxYDGUBpxmY4Sd+5QBHgCD4HtEvOA1Nqg2hZXcmREMfaYQdKa3qkX/6h/Uvs B8GG9Kyb5DRkS8NA7FGXDKVOuNrV+d2pMQDaQtjl1HqvHQld3bkP/7Vx8QcXLMYa kqHLyJ36NwZaWEs/PrMsuWG1su6W5c3fbVbzNcWsqenD7Gjc5tJzg9kXNIviVIC5 zWWF0AQwReuy4VxoM4EXYb7PcNVJIrLqdeLNmtJX5MvPwLZSxIiPzOhrHTkq39Bx v5md//8vFqY9GM8iZ3pqeDpSjAGqcXSWMsLS3KSYZYK5NaO9IfiIDXcnIcVulQZd ZhF8Bmvkry9JMp71kT0zjSMDLcLa4PHoZRqlQv2OGZkGvSDOWxP1OCNimJf6aOY1 3caPoPsjmsZOrxW8SIHxGX7bJCrtzDeTL/sXPFE9qaSu7pWuNZ/Rlk4vuAltAqI/ vnOK9wnIj5fk6njNCE01 =zHIA -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--