Date: Mon, 4 May 2015 12:58:13 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20150504105813.GD3676@noname.str.redhat.com>
References: <cover.1430388393.git.berto@igalia.com>
	<9b9c36f8c567da1f9561828380e8aa42c08b7efd.1430388393.git.berto@igalia.com>
	<20150501142321.GB2386@stefanha-thinkpad.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq"
Content-Disposition: inline
In-Reply-To: <20150501142321.GB2386@stefanha-thinkpad.redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/6] qcow2: use one single
 memory block for the L2/refcount cache tables
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-block@nongnu.org, Alberto Garcia <berto@igalia.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>


--JYK4vJDZwFMowpUq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Am 01.05.2015 um 16:23 hat Stefan Hajnoczi geschrieben:
> On Thu, Apr 30, 2015 at 01:11:40PM +0300, Alberto Garcia wrote:
> >  Qcow2Cache *qcow2_cache_create(BlockDriverState *bs, int num_tables)
> >  {
> >      BDRVQcowState *s =3D bs->opaque;
> >      Qcow2Cache *c;
> > -    int i;
> > =20
> >      c =3D g_new0(Qcow2Cache, 1);
> >      c->size =3D num_tables;
> > +    c->table_size =3D s->cluster_size;
>=20
> This assumes c->table_size meets bs' memory alignment requirements.  The
> following would be safer:
>=20
> c->table_size =3D QEMU_ALIGN_UP(c->table_size, bdrv_opt_mem_align(bs->fil=
e));

You can't just access more than one cluster. You might be caching data
and later write it back when it's stale.

If you can't do I/O in chunks as small as the cluster size (which is
rather unlikely), relying on bdrv_pwrite(), like Berto's patch does, is
the correct solution.

Kevin

--JYK4vJDZwFMowpUq
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVR1DEAAoJEH8JsnLIjy/WkqsP/Rcwy3GzvtLFSJTdjPdotolc
05EPx6wl63L7iYmWcjE58NILdtEuzF+R/aJ0dmI5ELvHd8wBsja+XForB8D4iIni
ltEE2BiODn5uN7KTrLig7GHIQ83jT6ZWI30Phf5HyL1OwofgVQYjQUZq7SsAxscd
zHfPhyM70ZUH2ZYpGcZUiLu3h16YScAodLCnkJevo37pPCEk1HrpmQavbwJEqyHp
T9bhMzS/VznPJxJ7D9kOj56sftc3Myg45kfryoTK4XR3NmFtsTdmcRFPRGgKIusw
JGN0jnOOOwLk6XkFSHqiCYjS6ynK7rMSAIXYvdFjRxNK1PX2bp3vevaS9zUun2b/
tM7RaMOKCDAfjzqvZ42p9vZ3i78ISauHMVUrZQIrE9W80m3b96JCIqd3O7BJelRN
gWtQb6AdvTGdmAFIYY5XScpZG8NoEKzj1PsVBDhesf76Ac3DtjQ64jIRkLMLpWtl
GgigePJF2JGOZQCG55TjofyDCZh+vsNHYcnAM8simFYsP11vNssrUZTUgTwboUNR
+pzPLakQunVNaJdaUroRLc/5dJigO99jKLR5SeYFOYsLxHQv7CYObQHIKhKcv0dy
c7prYHAsicbdUZtRwPJ9PDhxDAShTte6OiddgQjg8q34oXextii7H5/hE1rSOfD3
hL9LQKN1oo3R4BCNOAZs
=0KqL
-----END PGP SIGNATURE-----

--JYK4vJDZwFMowpUq--