From: Kevin Wolf <kwolf@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
stefanha@redhat.com, jsnow@redhat.com
Subject: Re: [PATCH v2 3/6] block/parallels: BDRVParallelsState: add cluster_size field
Date: Thu, 4 Mar 2021 16:11:41 +0100 [thread overview]
Message-ID: <20210304151141.GG9607@merkur.fritz.box> (raw)
In-Reply-To: <1891d7fb-a7fa-73fa-e6df-e3f281fa759c@openvz.org>
Am 04.03.2021 um 15:57 hat Denis V. Lunev geschrieben:
> On 3/4/21 5:24 PM, Kevin Wolf wrote:
> > Am 24.02.2021 um 11:47 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> We are going to use it in more places, calculating
> >> "s->tracks << BDRV_SECTOR_BITS" doesn't look good.
> >>
> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> >> @@ -771,6 +770,7 @@ static int parallels_open(BlockDriverState *bs, QDict *options, int flags,
> >> ret = -EFBIG;
> >> goto fail;
> >> }
> >> + s->cluster_size = s->tracks << BDRV_SECTOR_BITS;
> >>
> >> s->bat_size = le32_to_cpu(ph.bat_entries);
> >> if (s->bat_size > INT_MAX / sizeof(uint32_t)) {
> > Checking the context, I saw this a few lines above:
> >
> > if (s->tracks > INT32_MAX/513) {
> >
> > Is the 513 intentional?
> >
> > Kevin
> >
> I can not remember why I have written this at that time,
> but original comment for the commit was
>
> commit d25d59802021a747812472780d80a0e792078f40
> Author: Denis V. Lunev <den@openvz.org>
> Date: Mon Jul 28 20:23:55 2014 +0400
>
> parallels: 2TB+ parallels images support
>
> Parallels has released in the recent updates of Parallels Server 5/6
> new addition to his image format. Images with signature WithouFreSpacExt
> have offsets in the catalog coded not as offsets in sectors (multiple
> of 512 bytes) but offsets coded in blocks (i.e. header->tracks * 512)
>
> In this case all 64 bits of header->nb_sectors are used for image size.
>
> This patch implements support of this for qemu-img and also adds
> specific
> check for an incorrect image. Images with block size greater than
> INT_MAX/513 are not supported. The biggest available Parallels image
> cluster size in the field is 1 Mb. Thus this limit will not hurt
> anyone.
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Jeff Cody <jcody@redhat.com>
> CC: Kevin Wolf <kwolf@redhat.com>
> CC: Stefan Hajnoczi <stefanha@redhat.com>
> Reviewed-by: Jeff Cody <jcody@redhat.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>
> Thus I believe that this is intentional.
Hm, fair. It's a weird number. I would have guessed a typo, but if it's
in the commit message as well, it might be intentional. Or just a typo
combined with copy & paste.
If we ever remember or find a new reason why it has to be 513 rather
than 512, adding a comment would be nice.
Kevin
next prev parent reply other threads:[~2021-03-04 15:18 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 ` [PATCH v2 2/6] parallels.txt: fix bitmap L1 table description Vladimir Sementsov-Ogievskiy
2021-02-24 10:50 ` 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 [this message]
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=20210304151141.GG9607@merkur.fritz.box \
--to=kwolf@redhat.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).