All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, den@openvz.org, stefanha@redhat.com,
	mreitz@redhat.com, kwolf@redhat.com, jsnow@redhat.com,
	vsementsov@virtuozzo.com, eblake@redhat.com
Subject: [PATCH v2 2/6] parallels.txt: fix bitmap L1 table description
Date: Wed, 24 Feb 2021 13:47:03 +0300	[thread overview]
Message-ID: <20210224104707.88430-3-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20210224104707.88430-1-vsementsov@virtuozzo.com>

Actually L1 table entry offset is in 512 bytes sectors. Fix the spec.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 docs/interop/parallels.txt | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/docs/interop/parallels.txt b/docs/interop/parallels.txt
index f15bf35bd1..73af9a2c4b 100644
--- a/docs/interop/parallels.txt
+++ b/docs/interop/parallels.txt
@@ -208,21 +208,24 @@ of its data area are:
   28 - 31:    l1_size
               The number of entries in the L1 table of the bitmap.
 
-  variable:   l1_table (8 * l1_size bytes)
-              L1 offset table (in bytes)
+  variable:   L1 offset table (l1_table), size: 8 * l1_size bytes
 
-A dirty bitmap is stored using a one-level structure for the mapping to host
-clusters - an L1 table.
+Dirty bitmap is stored in the array of clusters inside Parallels Image file.
+Offsets of these clusters are saved in L1 offset table here. Each L1 table
+entry is a 64bit integer described below:
 
-Given an offset in bytes into the bitmap data, the offset in bytes into the
-image file can be obtained as follows:
+Given an offset in bytes into the bitmap data, corresponding L1 entry is
 
-    offset = l1_table[offset / cluster_size] + (offset % cluster_size)
+    l1_table[offset / cluster_size]
 
-If an L1 table entry is 0, the corresponding cluster of the bitmap is assumed
-to be zero.
+If L1 table entry is 0, all bits in the corresponding cluster of the bitmap
+are assumed to be 0.
 
-If an L1 table entry is 1, the corresponding cluster of the bitmap is assumed
-to have all bits set.
+If L1 table entry is 1, all bits in the corresponding cluster of the bitmap
+are assumed to be 1.
 
-If an L1 table entry is not 0 or 1, it allocates a cluster from the data area.
+If an L1 table entry is not 0 or 1, it contains corresponding cluster offset
+(in 512b sectors). Given an offset in bytes into the bitmap data the offset in
+bytes into the image file can be obtained as follows:
+
+    offset = l1_table[offset / cluster_size] * 512 + (offset % cluster_size)
-- 
2.29.2



  parent reply	other threads:[~2021-02-24 10:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24 10:47 [PATCH v2 0/6] parallels: load bitmap extension Vladimir Sementsov-Ogievskiy
2021-02-24 10:47 ` [PATCH v2 1/6] qcow2-bitmap: make bytes_covered_by_bitmap_cluster() public Vladimir Sementsov-Ogievskiy
2021-02-24 10:47 ` Vladimir Sementsov-Ogievskiy [this message]
2021-02-24 10:50   ` [PATCH v2 2/6] parallels.txt: fix bitmap L1 table description Denis V. Lunev
2021-03-04 14:21   ` Kevin Wolf
2021-02-24 10:47 ` [PATCH v2 3/6] block/parallels: BDRVParallelsState: add cluster_size field Vladimir Sementsov-Ogievskiy
2021-02-24 10:51   ` Denis V. Lunev
2021-03-04 14:24   ` Kevin Wolf
2021-03-04 14:57     ` Denis V. Lunev
2021-03-04 15:11       ` Kevin Wolf
2021-02-24 10:47 ` [PATCH v2 4/6] parallels: support bitmap extension for read-only mode Vladimir Sementsov-Ogievskiy
2021-02-26  8:42   ` Denis V. Lunev
2021-02-24 10:47 ` [PATCH v2 5/6] iotests.py: add unarchive_sample_image() helper Vladimir Sementsov-Ogievskiy
2021-02-24 10:49   ` Denis V. Lunev
2021-02-24 10:47 ` [PATCH v2 6/6] iotests: add parallels-read-bitmap test Vladimir Sementsov-Ogievskiy
2021-02-26  8:39   ` Denis V. Lunev
2021-03-04  9:51 ` [PATCH v2 7/6] MAINTAINERS: update parallels block driver Vladimir Sementsov-Ogievskiy
2021-03-04  9:56   ` Denis V. Lunev
2021-03-04  9:58   ` Vladimir Sementsov-Ogievskiy
2021-03-04 10:20     ` Denis V. Lunev
2021-03-04 14:40 ` [PATCH v2 0/6] parallels: load bitmap extension Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210224104707.88430-3-vsementsov@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=eblake@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.