From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beka5-0006By-4Y for qemu-devel@nongnu.org; Tue, 30 Aug 2016 11:04:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beka1-00013t-3M for qemu-devel@nongnu.org; Tue, 30 Aug 2016 11:04:05 -0400 Received: from mailhub.sw.ru ([195.214.232.25]:4558 helo=relay.sw.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beka0-00013l-Nw for qemu-devel@nongnu.org; Tue, 30 Aug 2016 11:04:01 -0400 References: <1470668720-211300-1-git-send-email-vsementsov@virtuozzo.com> <1470668720-211300-9-git-send-email-vsementsov@virtuozzo.com> <20160811131811.GF5035@noname.redhat.com> From: Vladimir Sementsov-Ogievskiy Message-ID: <57C5A04C.6080608@virtuozzo.com> Date: Tue, 30 Aug 2016 18:03:40 +0300 MIME-Version: 1.0 In-Reply-To: <20160811131811.GF5035@noname.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 08/29] qcow2-bitmap: delete bitmap from qcow2 after load List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, armbru@redhat.com, eblake@redhat.com, jsnow@redhat.com, famz@redhat.com, den@openvz.org, stefanha@redhat.com, pbonzini@redhat.com On 11.08.2016 16:18, Kevin Wolf wrote: > Am 08.08.2016 um 17:04 hat Vladimir Sementsov-Ogievskiy geschrieben: >> If we load bitmap for r/w bds, it's data in the image should be >> considered inconsistent from this point. Therefore it is safe to remove >> it from the image. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy > The approach that you're taking (keeping the complete bitmap directory > in memory in its on-disk format) means that we can't keep pointers to a > QCow2BitmapHeader anywhere because modifying the directory would move it > around. > > Did you consider using a different in-memory representation like a > normal list of structs? This would also allow you to use the normal list > iteration mechanisms (i.e. the existing *_FOREACH macros) instead of the > rather complex ones you need now. > > For example, qcow2 snapshots use a different on-disk and in-memory > format and the on-disk format is only implemented in the actual > read/write functions, and anything else can deal with the simpler > in-memory structures. > > Kevin Hmm. It was some kind of optimization (not to rewrite the whole directory when rewriting one entry).. But for now, after deciding to clear bitmap directory after reading bitmaps, it(my approach) obviously becomes unnecessary complication.. So, I will change this. -- Best regards, Vladimir