From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrP11-0000qw-9j for qemu-devel@nongnu.org; Thu, 20 Nov 2014 05:31:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrP0v-0004sP-5h for qemu-devel@nongnu.org; Thu, 20 Nov 2014 05:31:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrP0u-0004pz-VN for qemu-devel@nongnu.org; Thu, 20 Nov 2014 05:31:01 -0500 Date: Thu, 20 Nov 2014 11:30:53 +0100 From: Kevin Wolf Message-ID: <20141120103053.GA9266@noname.redhat.com> References: <1415365933-3727-1-git-send-email-fromani@redhat.com> <1415365933-3727-2-git-send-email-fromani@redhat.com> <20141117164936.GL16192@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20141117164936.GL16192@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [RFC][PATCH v2] block: add write threshold reporting for block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Francesco Romani , lcapitulino@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, mdroth@linux.vnet.ibm.com --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 17.11.2014 um 17:49 hat Stefan Hajnoczi geschrieben: > On Fri, Nov 07, 2014 at 02:12:13PM +0100, Francesco Romani wrote: > > +void bdrv_set_usage_threshold(BlockDriverState *bs, int64_t threshold_= bytes) > > +{ > > + BlockDriverState *target_bs =3D bs; > > + if (bs->file) { > > + target_bs =3D bs->file; > > + } >=20 > Hmm...I think now I understand why you are trying to use bs->file. This > is an attempt to make image formats work with the threshold. >=20 > Unfortunately the BlockDriverState topology can be more complicated than > just 1 level. >=20 > If we hardcode a strategy to traverse bs->file then it will work in most > cases: >=20 > while (bs->file) { > bs =3D bs->file; > } >=20 > But there are cases like VMDK extent files where a BlockDriverState > actually has multiple children. >=20 > One way to solve this is to require that the management tool tells QEMU > which exact BlockDriverState node the threshold applies to. Then QEMU > doesn't need any hardcoded policy. But I'm not sure how realistic that > it at the moment (whether management tools are uses node names for each > node yet), so it may be best to hardcode the bs->file traversal that > I've suggested. >=20 > Kevin: Do you agree? I have a feeling that we would regret this in the long run because it would allow only one special case of a general problem (watching a BDS). This means that we'll get inconsistent APIs. We're "only" talking about an optimisation here, even though a very useful one, so I wouldn't easily make compromises here. We should probably insist on using the node-name. Management tools need new code anyway to make use of the new functionality, so they can implement node-name support as well while they're at it. Kevin --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUbcLdAAoJEH8JsnLIjy/WcnoQAKah8HJ7Ou1+ZfWe7XZbP6Xf dtHjUmHCM1/BS+i+khAQCjKAY16owckWjp6+Jjsw4+nXKLEs7ds/lLA28y5SxDTn o6vxS1/Xi/PfxI4tttJqgU2+ii168zGZYgOTU4JFxKc5onHkQn30vl6C4VgjfbZm gY2Ut9lOsJitNj4pYRF6HGhR4SNENe/wpXItInD4M6N/2GkQKgvSVsMpWCu68BOg tThSDy49m9ihiHiPsOPVwFEP6qCA46HhdaUFmYkUB/2g6+SizAlrxa9sV4BDUx0p cxs4k4wJi112qsrGz9pZwlGJQMpv60rmfBvdJ1CZbixzoVq8LyYL+lQOdPJXCMn2 HyB3Kr5bJXi5KUfbZEfe5y5r6IilB2IIROCP+hY82O7FjL4oHMS9+WeJCSzVUpXU NE7NYEsc1H4C5cYf3zWSRHecIc+vsybr3xGCJFgr0vLc9B452Uph9oAwVFtWShOG YPCb8/VD+1NRM7PVy1ixhrnwHYb5LXVNL2Dc6Mz9CQ/+kAnbKwwYHSQkzaUmiRyj YD8FGMMzawGzcQKtqqsdPlrbrE6PTACS5f0KWtzAkkCtO704OhKqdAOM1fiAA/GZ D2mKEI3rqaxLI6q0ya00rBL+ze+OS3CeymI9QEnADr4DjSIX+ErOyNfwqna0qrpb aMHsQalUGllVCem4CeRz =jcPU -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--