All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V12 5/6] add-cow file format
Date: Wed, 12 Sep 2012 09:50:27 +0200	[thread overview]
Message-ID: <50503EC3.30403@redhat.com> (raw)
In-Reply-To: <CAGrFBshEo-o-gJVy-y6pcDQ6jW+Xr1HChW41PmmaULb9quq8jQ@mail.gmail.com>

Am 12.09.2012 09:28, schrieb Dong Xu Wang:
>>> +static bool is_allocated(BlockDriverState *bs, int64_t sector_num)
>>> +{
>>> +    BDRVAddCowState *s  = bs->opaque;
>>> +    BlockCache *c = s->bitmap_cache;
>>> +    int64_t cluster_num = sector_num / SECTORS_PER_CLUSTER;
>>> +    uint8_t *table      = NULL;
>>> +    uint64_t offset = ADD_COW_PAGE_SIZE * s->header.header_pages_size
>>> +        + (offset_in_bitmap(sector_num) & (~(c->entry_size - 1)));
>>> +    int ret = block_cache_get(bs, s->bitmap_cache, offset,
>>> +        (void **)&table, BLOCK_TABLE_BITMAP, ADD_COW_CACHE_ENTRY_SIZE);
>>
>> No matching block_cache_put?
>>
>>> +
>>> +    if (ret < 0) {
>>> +        return ret;
>>> +    }
>>> +    return table[cluster_num / 8 % ADD_COW_CACHE_ENTRY_SIZE]
>>> +        & (1 << (cluster_num % 8));
>>> +}
>>> +
>>> +static coroutine_fn int add_cow_is_allocated(BlockDriverState *bs,
>>> +        int64_t sector_num, int nb_sectors, int *num_same)
>>> +{
>>> +    BDRVAddCowState *s = bs->opaque;
>>> +    int changed;
>>> +
>>> +    if (nb_sectors == 0) {
>>> +        *num_same = 0;
>>> +        return 0;
>>> +    }
>>> +
>>> +    if (s->header.features & ADD_COW_F_All_ALLOCATED) {
>>> +        *num_same = nb_sectors - 1;
>>
>> Why - 1?
>>
>>> +        return 1;
>>> +    }
>>> +    changed = is_allocated(bs, sector_num);
>>> +
>>> +    for (*num_same = 1; *num_same < nb_sectors; (*num_same)++) {
>>> +        if (is_allocated(bs, sector_num + *num_same) != changed) {
>>> +            break;
>>> +        }
>>> +    }
>>> +    return changed;
>>> +}

>>> +static int bdrv_add_cow_truncate(BlockDriverState *bs, int64_t size)
>>> +{
>>> +    BDRVAddCowState *s = bs->opaque;
>>> +    int sector_per_byte = SECTORS_PER_CLUSTER * 8;
>>> +    int ret;
>>> +    uint32_t bitmap_pos = s->header.header_pages_size * ADD_COW_PAGE_SIZE;
>>> +    int64_t bitmap_size =
>>> +        (size / BDRV_SECTOR_SIZE + sector_per_byte - 1) / sector_per_byte;
>>> +    bitmap_size = (bitmap_size + ADD_COW_CACHE_ENTRY_SIZE - 1)
>>> +        & (~(ADD_COW_CACHE_ENTRY_SIZE - 1));
>>> +
>>> +    ret = bdrv_truncate(bs->file, bitmap_pos + bitmap_size);
>>> +    if (ret < 0) {
>>> +        return ret;
>>> +    }
>>> +    return 0;
>>> +}
>>
>> So you don't truncate s->image_file? Does this work?
> 
> s->image_file should be truncated? Image file can have a larger virtual size
> than backing_file, my understanding is we should not truncate image file.

I'm talking about s->image_hd, not bs->backing_hd. You are right that
the backing file should not be changed. But the associated raw image
should be resized, shouldn't it?

>>> +static coroutine_fn int add_cow_co_flush(BlockDriverState *bs)
>>> +{
>>> +    BDRVAddCowState *s = bs->opaque;
>>> +    int ret;
>>> +
>>> +    qemu_co_mutex_lock(&s->lock);
>>> +    ret = block_cache_flush(bs, s->bitmap_cache, BLOCK_TABLE_BITMAP,
>>> +        ADD_COW_CACHE_ENTRY_SIZE);
>>> +    qemu_co_mutex_unlock(&s->lock);
>>> +    return ret;
>>> +}
>>
>> What about flushing s->image_file?

>>> +typedef struct AddCowHeader {
>>> +    uint64_t        magic;
>>> +    uint32_t        version;
>>> +
>>> +    uint32_t        backing_filename_offset;
>>> +    uint32_t        backing_filename_size;
>>> +
>>> +    uint32_t        image_filename_offset;
>>> +    uint32_t        image_filename_size;
>>> +
>>> +    uint64_t        features;
>>> +    uint64_t        optional_features;
>>> +    uint32_t        header_pages_size;
>>> +} QEMU_PACKED AddCowHeader;
>>
>> Why aren't backing/image_file_format part of the header here? They are
>> in the spec. It would also simplify some offset calculation code.
>>
> 
> Anthony said "It's far better to shrink the size of the header and use
> an offset/len
> pointer to the backing file string.  Limiting backing files to 1023 is
> unacceptable"
> 
> http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg04110.html
> 
> So I use offset  and length instead of using string directly.

I'm talking about the format, not the path.

Kevin

  reply	other threads:[~2012-09-12  7:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10 15:39 [Qemu-devel] [PATCH V12 0/6] add-cow file format Dong Xu Wang
2012-08-10 15:39 ` [Qemu-devel] [PATCH V12 1/6] docs: document for " Dong Xu Wang
2012-09-06 17:27   ` Michael Roth
2012-09-10  1:48     ` Dong Xu Wang
2012-09-10 15:23   ` Kevin Wolf
2012-09-11  2:12     ` Dong Xu Wang
2012-08-10 15:39 ` [Qemu-devel] [PATCH V12 2/6] make path_has_protocol non-static Dong Xu Wang
2012-09-06 17:27   ` Michael Roth
2012-08-10 15:39 ` [Qemu-devel] [PATCH V12 3/6] qed_read_string to bdrv_read_string Dong Xu Wang
2012-09-06 17:32   ` Michael Roth
2012-09-10  1:49     ` Dong Xu Wang
2012-08-10 15:39 ` [Qemu-devel] [PATCH V12 4/6] rename qcow2-cache.c to block-cache.c Dong Xu Wang
2012-09-06 17:52   ` Michael Roth
2012-09-10  2:14     ` Dong Xu Wang
2012-09-11  8:41   ` Kevin Wolf
2012-08-10 15:39 ` [Qemu-devel] [PATCH V12 5/6] add-cow file format Dong Xu Wang
2012-09-06 20:19   ` Michael Roth
2012-09-10  2:25     ` Dong Xu Wang
2012-09-11  9:44       ` Kevin Wolf
2012-09-11  9:40   ` Kevin Wolf
2012-09-12  7:28     ` Dong Xu Wang
2012-09-12  7:50       ` Kevin Wolf [this message]
2012-08-10 15:39 ` [Qemu-devel] [PATCH V12 6/6] add-cow: add qemu-iotests support Dong Xu Wang
2012-09-11  9:55   ` Kevin Wolf
2012-08-23  5:34 ` [Qemu-devel] [PATCH V12 0/6] add-cow file format Dong Xu Wang

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=50503EC3.30403@redhat.com \
    --to=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wdongxu@linux.vnet.ibm.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.