From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuML1-0000TH-To for qemu-devel@nongnu.org; Thu, 26 Jul 2012 07:34:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuMKv-0008Tk-KP for qemu-devel@nongnu.org; Thu, 26 Jul 2012 07:34:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuMKv-0008TQ-C4 for qemu-devel@nongnu.org; Thu, 26 Jul 2012 07:34:33 -0400 Message-ID: <50112B2E.5020500@redhat.com> Date: Thu, 26 Jul 2012 13:34:06 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1343286523-8212-1-git-send-email-stefanha@linux.vnet.ibm.com> In-Reply-To: <1343286523-8212-1-git-send-email-stefanha@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] qemu-iotests: add qed.py image manipulation utility List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Am 26.07.2012 09:08, schrieb Stefan Hajnoczi: > The qed.py utility can inspect and manipulate QED image files. It can > be used for testing to see the state of image metadata and also to > inject corruptions into the image file. It also has a scrubbing feature > to copy just the metadata out of an image file, allowing users to share > broken image files without revealing data in bug reports. > > This has lived in my local repo for a long time but could be useful > to others. There are two use cases: > > 1. qemu-iotests that need to manipulate (e.g. corrupt) QED image files. > 2. Users that want to inspect or recover their QED image files. > > Signed-off-by: Stefan Hajnoczi > --- > Dong Xu Wang has contributed generic qemu-img info > support for fragmentation statistics and dirty flag status. I have dropped > fragmentation statistics from qed.py. Setting the dirty flag is still > supported in qed.py for testing. > > tests/qemu-iotests/qed.py | 234 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 234 insertions(+) > create mode 100755 tests/qemu-iotests/qed.py > +def random_table_item(table): > + return random.choice([(index, offset) for index, offset in enumerate(table) if offset != 0]) > + > +def corrupt_table_duplicate(table): > + '''Corrupt a table by introducing a duplicate offset''' > + _, dup_victim = random_table_item(table) > + > + for i in xrange(len(table)): > + dup_target = random.randint(0, len(table) - 1) > + if table[dup_target] != dup_victim: > + table[dup_target] = dup_victim > + return > + raise Exception('no duplication corruption possible in table') At least the message isn't quite correct. If you have a table that is mostly the same (probably unallocated), and has one allocated entry. In this situation the chances should be relatively high that the random number never hits the one different entry. Not sure how bad this "relatively high" really is, but I could imagine that we would see an occasional false positive if a test case used this. > +def cmd_need_check(qed, *args): > + '''need-check [on|off] - Test, set, or clear the QED_F_NEED_CHECK header bit''' > + if not args: > + print bool(qed.header['features'] & QED_F_NEED_CHECK) > + return > + > + if args[0] == 'on': > + qed.header['features'] |= QED_F_NEED_CHECK > + elif args[1] == 'off': args[0] > + qed.header['features'] &= ~QED_F_NEED_CHECK > + else: > + err('unrecognized sub-command') > + qed.store_header() > + > +def cmd_zero_cluster(qed, pos, *args): > + '''zero-cluster [] - Zero data clusters''' > + pos, n = int(pos), 1 > + if args: > + if len(args) != 1: > + err('expected one argument') > + n = int(args[0]) > + > + for i in xrange(n): > + l1_index = pos / qed.header['cluster_size'] / len(qed.l1_table) > + if qed.l1_table[l1_index] == 0: > + err('no l2 table allocated') > + > + l2_offset = qed.l1_table[l1_index] > + l2_table = qed.read_table(l2_offset) > + > + l2_index = (pos / qed.header['cluster_size']) % len(qed.l1_table) > + l2_table[l2_index] = 1 # zero the data cluster > + qed.write_table(l2_offset, l2_table) > + pos += qed.header['cluster_size'] Isn't it quite slow to write the table after each updated cluster? But okay, probably works good enough for small test cases. > +def cmd_copy_metadata(qed, outfile): > + '''copy-metadata - Copy metadata only (for scrubbing corrupted images)''' > + out = open(outfile, 'wb') > + > + # Match file size > + out.seek(qed.filesize - 1) > + out.write('\0') > + > + # Copy header clusters > + out.seek(0) > + header_size_bytes = qed.header['header_size'] * qed.header['cluster_size'] > + out.write(qed.raw_pread(0, header_size_bytes)) > + > + # Copy L1 table > + out.seek(qed.header['l1_table_offset']) > + s = ''.join(pack_table_elem(x) for x in qed.l1_table) > + out.write(s) > + > + # Copy L2 tables > + for l2_offset in qed.l1_table: > + if l2_offset == 0: > + continue > + l2_table = qed.read_table(l2_offset) > + out.seek(l2_offset) > + s = ''.join(pack_table_elem(x) for x in l2_table) > + out.write(s) > + > + out.close() Nice feature! :-) Kevin