From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDJZa-0002hZ-Lc for qemu-devel@nongnu.org; Mon, 19 Jan 2015 16:09:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDJZX-0000Qb-E8 for qemu-devel@nongnu.org; Mon, 19 Jan 2015 16:09:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDJZX-0000QX-5h for qemu-devel@nongnu.org; Mon, 19 Jan 2015 16:09:19 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0JL9IIv016402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 19 Jan 2015 16:09:18 -0500 Message-ID: <54BD727D.5010608@redhat.com> Date: Mon, 19 Jan 2015 16:09:17 -0500 From: Max Reitz MIME-Version: 1.0 References: <1421700544-24635-1-git-send-email-mreitz@redhat.com> <54BD7173.7060901@redhat.com> In-Reply-To: <54BD7173.7060901@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] qcow2: Add two more unalignment checks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi On 2015-01-19 at 16:04, Eric Blake wrote: > On 01/19/2015 01:49 PM, Max Reitz wrote: >> With the series adding unalignment checks and the series reworking the >> zero cluster expansion code overlapping, the unalignment checks have n= ot >> been implemented in the latter code. >> >> This series fixes it. >> >> There are other places which would require unalignment checks, like th= e >> offsets of L1 tables, especially for snapshots; but because it would b= e >> best to add these checks in the function which reads the snapshot tabl= e, >> this would make images with broken snapshots completely unusable, whic= h >> is something I opted to avoid for now. >> >> Ideally, we need to make the qcow2 repair function repair such cases, >> but until that is done there is not much we can do about them. > What's the best repair? That's what I was asking myself... > Read the data from the unaligned location, and > write a fresh copy into a new aligned allocation? Maybe. Maybe there is no way of repairing them and the only way is=20 asking the user whether it's fine to delete the snapshot (qemu-img check=20 -r make_consistent_whatever_it_takes). Also, the question remains for every unaligned data structure: L2=20 tables, data clusters=E2=80=A6 The refcount structures are the only ones = that=20 can be easily recovered. For data clusters, reading from the unaligned=20 location would probably be best; for L2 tables=E2=80=A6 maybe the same, t= hen run=20 a consistency check on the data and if it seems off=E2=84=A2, throw the w= hole L2=20 table away. > At any rate, I agree > that repairing unaligned locations is harder than detecting them, so > your series is fine as is. > > Reviewed-by: Eric Blake Thanks! Max