From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPXk4-0001mF-VV for qemu-devel@nongnu.org; Thu, 04 Sep 2014 10:10:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPXjy-0006XV-Pq for qemu-devel@nongnu.org; Thu, 04 Sep 2014 10:10:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPXjy-0006XQ-HH for qemu-devel@nongnu.org; Thu, 04 Sep 2014 10:10:22 -0400 Date: Thu, 4 Sep 2014 16:10:14 +0200 From: Kevin Wolf Message-ID: <20140904141014.GL3897@noname.str.redhat.com> References: <1409821121-20645-1-git-send-email-stefanha@redhat.com> <54085604.2050005@redhat.com> <20140904135132.GC27130@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <20140904135132.GC27130@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCH] cow: make padding in the header explicit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: shhuiw@163.com, qemu-devel@nongnu.org, Stefan Hajnoczi --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 04.09.2014 um 15:51 hat Stefan Hajnoczi geschrieben: > On Thu, Sep 04, 2014 at 06:07:32AM -0600, Eric Blake wrote: > > On 09/04/2014 02:58 AM, Stefan Hajnoczi wrote: > > > On-disk structures should be marked packed so the compiler does not > > > insert padding for field alignment. Padding should be explicit so > > > on-disk layout is obvious and we don't rely on the architecture-speci= fic > > > ABI for alignment rules. > > >=20 > > > The pahole(1) diff shows that the padding is now explicit and offsets > > > are unchanged: > > >=20 > > > char backing_file[1024]; /* 8 1024 */ > > > /* --- cacheline 16 boundary (1024 bytes) was 8 bytes ago --- */ > > > int32_t mtime; /* 1032 4 */ > > > - > > > - /* XXX 4 bytes hole, try to pack */ > > > - > > > + uint32_t padding; /* 1036 4 */ > > > uint64_t size; /* 1040 8 */ > >=20 > > Was a 32-bit build also inserting this padding, or do we have historical > > differences where 32-bit and 64-bit cow files are actually different, > > and we may need to be prepared to parse files from both sources? >=20 > Good point. Let's not merge this patch since it breaks 32-bit hosts. >=20 > The fact that no one hit problems when exchanging files between 32-bit > and 64-bit machines shows that the cow format is rarely used. >=20 > At this point we have 2 different formats: one without padding > (i386-style) and one with padding (x86_64-style). The chance of more > variants is small but who knows, maybe some other host architecture ABI > has yet another alignment rule for uint64_t. >=20 > I'd like to git rm block/cow.c but I suppose the backwards-compatible > thing to do is to introduce subformats to support both variants. > Opinions? Can we safely detect which of the subformats we have? But I'm not sure if it's even worth fixing. Kevin --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUCHLGAAoJEH8JsnLIjy/Wr1MP/Rww5CiGbjkW4UTTeUlgTm8c 0YiYVtzaDwSRsjVVXPINe1B32Gm3+MRyJSzzFLz0LovT5hZbK4h4EvDD1dVBFs+i AlR4Vb8JfthFKW+jQgPVm1nHJroEWCchWLtHI49oWaI0sH2s7t5JI34rfs1LxqFc lLWZjgqdVkzogppQazrwNnsgQbwkqzXGaT5SBGiaU41x9/cT6uYVBv8RCV2yFgDV TAYBMl98mKlutrR/XfwA64T6QUDqZJAOn1DWsJBcEWlqdfZv7+wOMMIC9sAZry4n FwkyMhvgm9jmQoqg1Ai+avIMbmWnSevxc98UZ7p0QZrp1elPc9eAt+U6iT/pZMTc IY/FuoDMiNkgQchu917YG+aTY4xoReknOSBit1P2Y7Mi0rtClZAVxGhiQa2VSXSL LYZqL2wRQCmiqX/p/FkL8Vap/eHqrFcgSM8lDweNqrco51qL3sY6I8pe1FFyafDk sDdJHx29of/4QzM6RapzPE7wt7qNNK5kjF+d190TqS+H1xzRGD8CnYJUHow3IIHp Lt6c+F3s3nq6pBskE+rm/QyeqWy48lQ6aipeAuuRqGqUuehGCIK03c7zWV8sHYr0 SmszUMpTIc3h38fiobVoKa/ScSSYPKYVBX4ed908Bu0+htgtpOyCpLGgJ+FqRVOt gMdCOggHcCI8V+zqBvW5 =vMQm -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR--