On 7/9/19 7:25 PM, John Snow wrote:
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 416 +++
> tests/qemu-iotests/257.out | 2247
> tests/qemu-iotests/group |1 +
> 3 files changed, 2664 insertions(+)
> create mode 100755
On Wed, 2019-07-10 at 23:09 +0200, Kevin Wolf wrote:
> Am 10.07.2019 um 13:33 hat Paolo Bonzini geschrieben:
> > On 10/07/19 13:02, Kevin Wolf wrote:
> > > Hm... Actually, file-posix implements .bdrv_check_perm and could just
> > > refuse attaching a parent there if it doesn't request a specific
>
On 10.07.19 23:24, Max Reitz wrote:
> On 10.07.19 19:03, Maxim Levitsky wrote:
>> preallocation=off and preallocation=metadata
>> both allocate luks header only, and preallocation=falloc/full
>> is passed to underlying file, with the given image size.
>>
>> Note that the actual preallocated size
Ping
I suppose I’ll apply the patches I had in v1 if I don’t get reviews for
the new patches, because some fixes are better than none.
(And probably patch 2, because it’s obvious.)
Max
On 03.07.19 19:28, Max Reitz wrote:
> This is a v2 to “block: Add BDS.never_freeze”.
>
> It depends on my
On 10.07.19 19:03, Maxim Levitsky wrote:
> preallocation=off and preallocation=metadata
> both allocate luks header only, and preallocation=falloc/full
> is passed to underlying file, with the given image size.
>
> Note that the actual preallocated size is a bit smaller due
> to luks header.
Am 10.07.2019 um 13:33 hat Paolo Bonzini geschrieben:
> On 10/07/19 13:02, Kevin Wolf wrote:
> > Hm... Actually, file-posix implements .bdrv_check_perm and could just
> > refuse attaching a parent there if it doesn't request a specific
> > permission like BLK_PERM_SUPPORT_ZONED. That should give
On 10.07.19 16:57, Michal Privoznik wrote:
> When creating the admin queue in nvme_init() the variable that
> holds the number of queues created is modified before actual
> queue creation. This is a problem because if creating the queue
> fails then the variable is left in inconsistent state. This
On 10.07.19 22:47, John Snow wrote:
>
>
> On 7/10/19 4:30 PM, Max Reitz wrote:
>> On 10.07.19 20:20, John Snow wrote:
>>>
>>>
>>> On 7/10/19 12:36 PM, Max Reitz wrote:
On 10.07.19 03:05, John Snow wrote:
> The way bitmap backups work is by starting at 75% if it needs
> to copy just
On 10.07.19 21:00, John Snow wrote:
>
>
> On 7/10/19 1:14 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> Signed-off-by: John Snow
>>> ---
>>> tests/qemu-iotests/257 | 31 +
>>> tests/qemu-iotests/257.out | 3089
>>> 2 files changed,
On 7/10/19 4:30 PM, Max Reitz wrote:
> On 10.07.19 20:20, John Snow wrote:
>>
>>
>> On 7/10/19 12:36 PM, Max Reitz wrote:
>>> On 10.07.19 03:05, John Snow wrote:
The way bitmap backups work is by starting at 75% if it needs
to copy just 25% of the disk.
>>>
>>> Although there is this
On 10.07.19 20:32, John Snow wrote:
>
>
> On 7/10/19 12:48 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> Accept bitmaps and sync policies for the other backup modes.
>>> This allows us to do things like create a bitmap synced to a full backup
>>> without a transaction, or start
On 10.07.19 20:20, John Snow wrote:
>
>
> On 7/10/19 12:36 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> The way bitmap backups work is by starting at 75% if it needs
>>> to copy just 25% of the disk.
>>
>> Although there is this comment:
>>
>>> /* TODO
On 10.07.19 19:57, John Snow wrote:
>
>
> On 7/10/19 12:11 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> This is nicer to do in the unified QMP interface that we have now,
>>> because it lets us use the right terminology back at the user.
>>>
>>> Signed-off-by: John Snow
>>>
On 10.07.19 19:52, John Snow wrote:
>
>
> On 7/10/19 12:04 PM, Max Reitz wrote:
>> On 10.07.19 03:05, John Snow wrote:
>>> This test needs support for non-bitmap backups and missing or
>>> unspecified bitmap sync modes, so rewrite the helpers to be a little
>>> more generic.
>>>
>>>
Sphinx, through Pygments, does not like annotated json examples very
much. In some versions of Sphinx (1.7), it will render the non-json
portions of code blocks in red, but in newer versions (2.0) it will
throw an exception and not highlight the block at all. Though we can
suppress this warning,
Pygments and Sphinx get pickier all the time; Sphinx 2.1+ now catches
these errors.
Signed-off-by: John Snow
Reported-by: Aarushi Mehta
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-id: 20190603214653.29369-2-js...@redhat.com
Signed-off-by: John Snow
---
docs/interop/bitmaps.rst | 4 ++--
The following changes since commit 6df2cdf44a82426f7a59dcb03f0dd2181ed7fdfa:
Update version for v4.1.0-rc0 release (2019-07-09 17:21:53 +0100)
are available in the Git repository at:
https://github.com/jnsnow/qemu.git tags/bitmaps-pull-request
for you to fetch changes up to
The annotated style json we use in QMP documentation is not strict json
and depending on the version of Sphinx (2.0+) or Pygments installed,
might cause the build to fail.
Use the new QMP lexer.
Further, some versions of Sphinx can not apply custom lexers to "code"
directives and require the use
On 7/10/19 1:14 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/257 | 31 +
>> tests/qemu-iotests/257.out | 3089
>> 2 files changed, 3120 insertions(+)
>
> Oof.
>
Yeah, it's... a
On 7/10/19 12:48 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Accept bitmaps and sync policies for the other backup modes.
>> This allows us to do things like create a bitmap synced to a full backup
>> without a transaction, or start a resumable backup process.
>>
>> Some
On 7/10/19 12:36 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> The way bitmap backups work is by starting at 75% if it needs
>> to copy just 25% of the disk.
>
> Although there is this comment:
>
>> /* TODO job_progress_set_remaining() would make more sense */
>
> So...
>
>>
On 7/10/19 12:22 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/257 | 69 +++
>> tests/qemu-iotests/257.out | 85 ++
>> 2 files changed, 154 insertions(+)
On 7/10/19 12:11 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> This is nicer to do in the unified QMP interface that we have now,
>> because it lets us use the right terminology back at the user.
>>
>> Signed-off-by: John Snow
>> ---
>> block/backup.c | 13 -
>>
On 7/10/19 12:04 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> This test needs support for non-bitmap backups and missing or
>> unspecified bitmap sync modes, so rewrite the helpers to be a little
>> more generic.
>>
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/257
On 7/10/19 11:47 AM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Represent a bitmap with an object that we can mark and clear bits in.
>> This makes it easier to manage partial writes when we don't write a
>> full group's worth of patterns before an error.
>>
>> Signed-off-by:
On 7/10/19 12:26 PM, Max Reitz wrote:
> On 10.07.19 03:05, John Snow wrote:
>> Just kidding, this is easier to manage with a full class instead of a
>> namedtuple.
>>
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/257 | 58 +++---
>> 1 file
On 7/10/19 10:48 AM, Max Reitz wrote:
> On 10.07.19 01:25, John Snow wrote:
>> This series adds a new "BITMAP" sync mode that is meant to replace the
>> existing "INCREMENTAL" sync mode.
>
> So who’s going to take it? :-)
>
> get_maintainer.pl says I’m responsible for 14/18 patches, and you
On 10.07.19 03:05, John Snow wrote:
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 31 +
> tests/qemu-iotests/257.out | 3089
> 2 files changed, 3120 insertions(+)
Oof.
> diff --git a/tests/qemu-iotests/257 b/tests/qemu-iotests/257
>
On Wed, 2019-07-10 at 17:34 +0200, Philippe Mathieu-Daudé wrote:
> On 7/10/19 4:57 PM, Michal Privoznik wrote:
> > When creating the admin queue in nvme_init() the variable that
> > holds the number of queues created is modified before actual
> > queue creation. This is a problem because if
preallocation=off and preallocation=metadata
both allocate luks header only, and preallocation=falloc/full
is passed to underlying file, with the given image size.
Note that the actual preallocated size is a bit smaller due
to luks header.
Fixes:
On 10.07.19 03:05, John Snow wrote:
> Accept bitmaps and sync policies for the other backup modes.
> This allows us to do things like create a bitmap synced to a full backup
> without a transaction, or start a resumable backup process.
>
> Some combinations don't make sense, though:
>
> - NEVER
On 10.07.19 03:05, John Snow wrote:
> The way bitmap backups work is by starting at 75% if it needs
> to copy just 25% of the disk.
Although there is this comment:
> /* TODO job_progress_set_remaining() would make more sense */
So...
> The way sync=top currently works, however, is to start at
On 10.07.19 03:05, John Snow wrote:
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 69 +++
> tests/qemu-iotests/257.out | 85 ++
> 2 files changed, 154 insertions(+)
>
> diff --git a/tests/qemu-iotests/257
On 10.07.19 03:05, John Snow wrote:
> Just kidding, this is easier to manage with a full class instead of a
> namedtuple.
>
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 58 +++---
> 1 file changed, 32 insertions(+), 26 deletions(-)
>
> diff
On 10.07.19 03:05, John Snow wrote:
> This is nicer to do in the unified QMP interface that we have now,
> because it lets us use the right terminology back at the user.
>
> Signed-off-by: John Snow
> ---
> block/backup.c | 13 -
> blockdev.c | 10 ++
> 2 files changed,
On 10.07.19 03:05, John Snow wrote:
> This test needs support for non-bitmap backups and missing or
> unspecified bitmap sync modes, so rewrite the helpers to be a little
> more generic.
>
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 46 +
>
On 10.07.19 03:05, John Snow wrote:
> Represent a bitmap with an object that we can mark and clear bits in.
> This makes it easier to manage partial writes when we don't write a
> full group's worth of patterns before an error.
>
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 125
On 7/10/19 4:57 PM, Michal Privoznik wrote:
> When creating the admin queue in nvme_init() the variable that
> holds the number of queues created is modified before actual
> queue creation. This is a problem because if creating the queue
> fails then the variable is left in inconsistent state.
On Tue, Jul 09, 2019 at 09:42:14PM -0400, Jason Dillaman wrote:
> On Tue, Jul 9, 2019 at 11:32 AM Max Reitz wrote:
> > On 09.07.19 15:09, Stefano Garzarella wrote:
> > >
> > > Max, Jason, thanks for the details!
> > >
> > > If you agree, I'll try to implement something similar, iterating on all
>
On 10.07.19 03:05, John Snow wrote:
> Just kidding, this is easier to manage with a full class instead of a
> namedtuple.
>
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 58 +++---
> 1 file changed, 32 insertions(+), 26 deletions(-)
When creating the admin queue in nvme_init() the variable that
holds the number of queues created is modified before actual
queue creation. This is a problem because if creating the queue
fails then the variable is left in inconsistent state. This was
actually observed when I tried to hotplug a
On 10.07.19 01:25, John Snow wrote:
> This series adds a new "BITMAP" sync mode that is meant to replace the
> existing "INCREMENTAL" sync mode.
So who’s going to take it? :-)
get_maintainer.pl says I’m responsible for 14/18 patches, and you are
for 9/18. But you did prefix the title with
On 10.07.19 01:25, John Snow wrote:
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/257 | 416 +++
> tests/qemu-iotests/257.out | 2247
> tests/qemu-iotests/group |1 +
> 3 files changed, 2664 insertions(+)
> create mode 100755
On 10.07.19 01:25, John Snow wrote:
> This simplifies some interface matters; namely the initialization and
> (later) merging the manifest back into the sync_bitmap if it was
> provided.
>
> Signed-off-by: John Snow
> ---
> block/backup.c | 81 ++
On 10.07.19 01:25, John Snow wrote:
> I'm surprised it didn't come up sooner, but sometimes we have a +busy
> bitmap as a source. This is dangerous from the QMP API, but if we are
> the owner that marked the bitmap busy, it's safe to merge it using it as
> a read only source.
>
> It is not safe
On Thu, 2019-07-04 at 15:43 +0300, Maxim Levitsky wrote:
> Regular kernel block devices (/dev/sda*, /dev/nvme*, etc) don't have
> max segment size/max segment count hardware requirements exposed
> to the userspace, but rather the kernel block layer
> takes care to split the incoming requests that
On 10/07/19 13:02, Kevin Wolf wrote:
> Hm... Actually, file-posix implements .bdrv_check_perm and could just
> refuse attaching a parent there if it doesn't request a specific
> permission like BLK_PERM_SUPPORT_ZONED. That should give us the
> whitelist semantics through existing infrastructure.
Am 10.07.2019 um 12:09 hat Paolo Bonzini geschrieben:
> On 09/07/19 22:38, Dmitry Fomichev wrote:
> > Currently, attaching zoned block devices (i.e. storage devices
> > compliant to ZAC/ZBC standards) using several virtio methods doesn't
> > work - the zoned devices appear as regular block devices
On 09/07/19 22:38, Dmitry Fomichev wrote:
> Currently, attaching zoned block devices (i.e. storage devices
> compliant to ZAC/ZBC standards) using several virtio methods doesn't
> work - the zoned devices appear as regular block devices at the guest.
> This may cause unexpected i/o errors and,
Am 09.07.2019 um 18:23 hat Dan Shearer geschrieben:
> ddb is now available at https://github.com/gladserv/ddb and is intended for
> comparing block devices. The definition of "device" is very broad and can be
> custom-defined.
>
> ddb also knows about sparse files.
How does this compare to
50 matches
Mail list logo
