On 2 October 2018 at 21:11, John Snow wrote:
>
>
> On 10/01/2018 09:20 AM, Peter Maydell wrote:
>> The test-bdrv-drain and test-replication tests have
>> intermittent errors which make my build testing process
>> fail way too often. Disable them both for the moment.
>>
>> Signed-off-by: Peter Mayd
02.10.2018 23:19, Eric Blake wrote:
> On 10/1/18 5:29 AM, Vladimir Sementsov-Ogievskiy wrote:
>> v2 was "[RFC v2] new, node-graph-based fleecing and backup"
>>
>> Hi all!
>>
>> These series introduce fleecing-hook driver. It's a filter-node, which
>> do copy-before-write operation. Mirror uses filt
Signed-off-by: Alberto Garcia
---
block.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index 7710b399a3..0d6e5f1a76 100644
--- a/block.c
+++ b/block.c
@@ -1327,7 +1327,7 @@ QemuOptsList bdrv_runtime_opts = {
.help = "try to optimize zero
On 10/2/18 6:02 PM, John Snow wrote:
Instead of both frozen and qmp_locked checks, wrap it into one check.
frozen implies the bitmap is split in two (for backup), and shouldn't
be modified. qmp_locked implies it's being used by another operation,
like being exported over NBD. In both cases it mea
On 10/2/18 6:02 PM, John Snow wrote:
In prior commits that made merge transactionable, we removed the
assertion that merge cannot operate on disabled bitmaps. In addition,
we want to make sure that we are prohibiting merges to "locked" bitmaps.
Use the new user_locked function to check.
Reporte
On 10/2/18 6:02 PM, John Snow wrote:
Similarly to merge, it's OK to allow clear operations on disabled
bitmaps, as this condition only means that they are not recording
new writes. We are free to clear it if the user requests it.
Signed-off-by: John Snow
---
block/dirty-bitmap.c | 1 -
block
On 10/2/18 6:02 PM, John Snow wrote:
We're not being consistent about this. If it's in use by an operation,
the user should not be able to change the behavior of that bitmap.
Signed-off-by: John Snow
---
blockdev.c | 26 --
1 file changed, 20 insertions(+), 6 deletion
On 10/2/18 6:02 PM, John Snow wrote:
Whether it's "locked" or "frozen", it's in use and should
not be allowed for the purposes of this operation.
Signed-off-by: John Snow
---
nbd/server.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nbd/server.c b/nbd/server.c
inde
On 10/2/18 6:02 PM, John Snow wrote:
If the bitmap is frozen, we shouldn't touch it.
Signed-off-by: John Snow
---
blockdev.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index d0febfca79..098d4c337f 100644
--- a/blockdev.c
+++ b/blo
03.10.2018 02:02, John Snow wrote:
Instead of both frozen and qmp_locked checks, wrap it into one check.
frozen implies the bitmap is split in two (for backup), and shouldn't
be modified. qmp_locked implies it's being used by another operation,
like being exported over NBD. In both cases it means
03.10.2018 02:02, John Snow wrote:
> Similarly to merge, it's OK to allow clear operations on disabled
> bitmaps, as this condition only means that they are not recording
> new writes. We are free to clear it if the user requests it.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Sementsov-Og
03.10.2018 02:02, John Snow wrote:
> In prior commits that made merge transactionable, we removed the
> assertion that merge cannot operate on disabled bitmaps. In addition,
> we want to make sure that we are prohibiting merges to "locked" bitmaps.
>
> Use the new user_locked function to check.
>
>
03.10.2018 02:02, John Snow wrote:
> We're not being consistent about this. If it's in use by an operation,
> the user should not be able to change the behavior of that bitmap.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Sementsov-Ogievskiy
> ---
> blockdev.c | 26 -
03.10.2018 15:28, Eric Blake wrote:
> On 10/2/18 6:02 PM, John Snow wrote:
>> If the bitmap is frozen, we shouldn't touch it.
>>
>> Signed-off-by: John Snow
>> ---
>> blockdev.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/blockdev.c b/blockdev.c
>> i
03.10.2018 02:02, John Snow wrote:
> If the bitmap is frozen, we shouldn't touch it.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Sementsov-Ogievskiy
> ---
> blockdev.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index
Reviewed-by: Vladimir Sementsov-Ogievskiy
03.10.2018 02:02, John Snow wrote:
> Whether it's "locked" or "frozen", it's in use and should
> not be allowed for the purposes of this operation.
>
> Signed-off-by: John Snow
> ---
> nbd/server.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deleti
On 10/1/18 5:29 AM, Vladimir Sementsov-Ogievskiy wrote:
It is needed for use the bitmaps in backup. "disabled" means that
bitmap is not auto set by writes. Let's allow changing bitmap for other
uses.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/dirty-bitmap.c | 2 --
1 file changed,
03.10.2018 02:33, John Snow wrote:
> From: Eric Blake
>
> We need an accurate count of the number of bits set in a bitmap
> after a merge. In particular, since the merge operation short-circuits
> a merge from an empty source, if you have bitmaps A, B, and C where
> B started empty, then merge C i
We should not go to structured-read branch on CACHE command, fix that.
Bug intoroduced in bc37b06a5cde24 "nbd/server: introduce NBD_CMD_CACHE"
with the whole feature and affects 3.0.0 release.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 3 ++-
1 file changed, 2 insertions(+),
On 10/3/18 9:32 AM, Vladimir Sementsov-Ogievskiy wrote:
03.10.2018 02:33, John Snow wrote:
From: Eric Blake
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A
03.10.2018 17:23, Eric Blake wrote:
> On 10/1/18 5:29 AM, Vladimir Sementsov-Ogievskiy wrote:
>> It is needed for use the bitmaps in backup. "disabled" means that
>> bitmap is not auto set by writes. Let's allow changing bitmap for other
>> uses.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>
On 10/3/18 9:47 AM, Vladimir Sementsov-Ogievskiy wrote:
We should not go to structured-read branch on CACHE command, fix that.
Bug intoroduced in bc37b06a5cde24 "nbd/server: introduce NBD_CMD_CACHE"
s/intoroduced/introduced/
with the whole feature and affects 3.0.0 release.
Ouch. It's beca
03.10.2018 17:57, Eric Blake wrote:
> On 10/3/18 9:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>> We should not go to structured-read branch on CACHE command, fix that.
>>
>> Bug intoroduced in bc37b06a5cde24 "nbd/server: introduce NBD_CMD_CACHE"
>
> s/intoroduced/introduced/
>
>> with the whole fea
02.10.2018 23:19, Eric Blake wrote:
> On 10/1/18 5:29 AM, Vladimir Sementsov-Ogievskiy wrote:
>> v2 was "[RFC v2] new, node-graph-based fleecing and backup"
>>
>> Hi all!
>>
>> These series introduce fleecing-hook driver. It's a filter-node, which
>> do copy-before-write operation. Mirror uses filt
[redirecting this to NBD list]
On 10/3/18 10:36 AM, Vladimir Sementsov-Ogievskiy wrote:
hmm, about different ports, it's funny, but NBD-spec is directly against
different ports for new style negotiation:
A client who wants to use the new style negotiation SHOULD connect on
the IANA-reserved por
On 2 October 2018 at 09:06, Peter Maydell wrote:
> I still got a hang on OSX on test-bdrv-drain, but I've applied
> this anyway, since hopefully it fixes the other intermittent
> failure and may reduce the likelihood with the test-bdrv-drain.
OSX seems to fail test-bdrv-drain fairly frequently. H
On 10/03/2018 08:28 AM, Eric Blake wrote:
> On 10/2/18 6:02 PM, John Snow wrote:
>> If the bitmap is frozen, we shouldn't touch it.
>>
>> Signed-off-by: John Snow
>> ---
>> blockdev.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/blockdev.c b/blockd
It's unexpected behavior that without -x option qemu-nbd do old-style
negotiation. Let's use "" as a default name instead (as it is already
done if tls is used) and therefore, drop old-style negotiation from
Qemu NBD server.
Vladimir Sementsov-Ogievskiy (2):
qemu-nbd: drop old-style negotiation
Use new-style negotiation always, with default "" (empty) export name
if it is not specified with '-x' option.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
qemu-nbd.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 5
After the previous commit, nbd_client_new first parameter is always
NULL. Let's drop it with all corresponding old-style negotiation code
path which is unreachable now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/nbd.h | 3 +--
blockdev-nbd.c | 2 +-
nbd/server.c
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
to newstyle (with an empty export name) and fall back to oldstyle
only on an explicit request.
On 10/3/18 12:02 PM, Vladimir Sementsov-Ogievskiy wrote:
Use new-style negotiation always, with default "" (empty) export name
if it is not specified with '-x' option.
If we like this approach (over mine of keeping oldstyle, but via an
explicit -O option), then this commit message should add t
On 10/3/18 12:19 PM, Eric Blake wrote:
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
to newstyle (with an empty export name) and fall back
On 10/3/18 12:02 PM, Vladimir Sementsov-Ogievskiy wrote:
It's unexpected behavior that without -x option qemu-nbd do old-style
negotiation. Let's use "" as a default name instead (as it is already
done if tls is used) and therefore, drop old-style negotiation from
Qemu NBD server.
Oddly enough,
On 10/3/18 12:02 PM, Vladimir Sementsov-Ogievskiy wrote:
After the previous commit, nbd_client_new first parameter is always
NULL. Let's drop it with all corresponding old-style negotiation code
path which is unreachable now.
Being able to force oldstyle negotiation for interoperability testing
03.10.2018 20:19, Eric Blake wrote:
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
to newstyle (with an empty export name) and fall back to
On 10/3/18 12:38 PM, Vladimir Sementsov-Ogievskiy wrote:
03.10.2018 20:19, Eric Blake wrote:
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
to newstyle (with an empty export name) and fall back to oldstyle
only on an explicit request.
03.10.2018 20:32, Eric Blake wrote:
On 10/3/18 12:02 PM, Vladimir Sementsov-Ogievskiy wrote:
It's unexpected behavior that without -x option qemu-nbd do old-style
negotiation. Let's use "" as a default name instead (as it is already
done if tls is used) and therefore, drop old-style negotiation fro
Commit 145614a1 introduced --tls-creds, but forgot to document
it in 'qemu-nbd --help'.
Signed-off-by: Eric Blake
---
Sadly, 'git grep -i "qemu.nbd.*tls"' has no hits, making me wonder
if our iotests are even covering this.
Noticed while writing my other patches for defaulting to newstyle.
---
On Wed, Oct 03, 2018 at 10:45:29AM -0500, Eric Blake wrote:
> [redirecting this to NBD list]
>
> On 10/3/18 10:36 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> > hmm, about different ports, it's funny, but NBD-spec is directly against
> > different ports for new style negotiation:
> > A client who
On 10/3/18 12:59 PM, Vladimir Sementsov-Ogievskiy wrote:
03.10.2018 20:32, Eric Blake wrote:
On 10/3/18 12:02 PM, Vladimir Sementsov-Ogievskiy wrote:
It's unexpected behavior that without -x option qemu-nbd do old-style
negotiation. Let's use "" as a default name instead (as it is already
done if
03.10.2018 20:55, Eric Blake wrote:
> Oldstyle NBD negotiation cannot perform any of the extensions that
> we have recently been relying on. While you can always pass -x ""
> to get newstyle negotiation, these days, it is better to just default
> to newstyle (with an empty export name) and fall ba
On 10/03/2018 08:47 AM, Vladimir Sementsov-Ogievskiy wrote:
> 03.10.2018 02:02, John Snow wrote:
>> Instead of both frozen and qmp_locked checks, wrap it into one check.
>> frozen implies the bitmap is split in two (for backup), and shouldn't
>> be modified. qmp_locked implies it's being used by
03.10.2018 20:55, Eric Blake wrote:
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
to newstyle (with an empty export name) and fall back to o
On 10/3/18 1:28 PM, John Snow wrote:
Thanks, I'll just make these edits and trust that Eric is fine with it
as well.
Yes, works for me
--js
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
01.10.2018 13:29, Vladimir Sementsov-Ogievskiy wrote:
> Drop write notifiers and use filter node instead. Changes:
>
> 1. copy-before-writes now handled by filter node, so, drop all
> is_write_notifier arguments.
>
> 2. we don't have intersecting requests, so their handling is dropped.
> Instea
On 10/03/2018 10:49 AM, Eric Blake wrote:
> On 10/3/18 9:32 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 03.10.2018 02:33, John Snow wrote:
>>> From: Eric Blake
>>>
>>> We need an accurate count of the number of bits set in a bitmap
>>> after a merge. In particular, since the merge operation shor
On 10/3/18 2:57 PM, John Snow wrote:
- I always forget to update this field.. We definitely should add some
generic check on it somewhere, at least in tests.
My suggestion (in another thread) was to enhance
x-debug-block-dirty-bitmap-sha256 to include 'count' alongside the
checksum, to mak
On 10/03/2018 02:04 PM, Eric Blake wrote:
> Commit 145614a1 introduced --tls-creds, but forgot to document
> it in 'qemu-nbd --help'.
>
> Signed-off-by: Eric Blake
>
> ---
> Sadly, 'git grep -i "qemu.nbd.*tls"' has no hits, making me wonder
> if our iotests are even covering this.
>
> Notice
FWIW I don't have anything to add - agree with what's been said already.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot
On 10/3/18 3:35 PM, John Snow wrote:
On 10/03/2018 02:04 PM, Eric Blake wrote:
Commit 145614a1 introduced --tls-creds, but forgot to document
it in 'qemu-nbd --help'.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
Do we have a manpage/texi that needs to update, too?
No; commit 1456
On 10/02/2018 07:02 PM, John Snow wrote:
> based on: jsnow/bitmaps staging branch
>
> This series builds on a previous standalone patch and adjusts
> the permission for all (or most) of the QMP bitmap commands.
>
> V4:
> - Replace "in-use" with "in use"
> - Replace "user_modifiable" version
On 10/3/18 12:55 PM, Eric Blake wrote:
Oldstyle NBD negotiation cannot perform any of the extensions that
we have recently been relying on. While you can always pass -x ""
to get newstyle negotiation, these days, it is better to just default
to newstyle (with an empty export name) and fall back
On 10/3/18 1:04 PM, Eric Blake wrote:
Commit 145614a1 introduced --tls-creds, but forgot to document
it in 'qemu-nbd --help'.
Signed-off-by: Eric Blake
---
Sadly, 'git grep -i "qemu.nbd.*tls"' has no hits, making me wonder
if our iotests are even covering this.
Noticed while writing my other
On 10/03/2018 04:42 PM, Eric Blake wrote:
> On 10/3/18 3:35 PM, John Snow wrote:
>>
>>
>> On 10/03/2018 02:04 PM, Eric Blake wrote:
>>> Commit 145614a1 introduced --tls-creds, but forgot to document
>>> it in 'qemu-nbd --help'.
>>>
>>> Signed-off-by: Eric Blake
>>>
>
>> Reviewed-by: John Snow
On 10/3/18 12:02 PM, Vladimir Sementsov-Ogievskiy wrote:
It's unexpected behavior that without -x option qemu-nbd do old-style
negotiation. Let's use "" as a default name instead (as it is already
done if tls is used) and therefore, drop old-style negotiation from
Qemu NBD server.
Vladimir Semen
On 10/02/2018 07:33 PM, John Snow wrote:
> From: Eric Blake
>
> We need an accurate count of the number of bits set in a bitmap
> after a merge. In particular, since the merge operation short-circuits
> a merge from an empty source, if you have bitmaps A, B, and C where
> B started empty, then
From: Vladimir Sementsov-Ogievskiy
Use new-style negotiation always, with default "" (empty) export name
if it is not specified with '-x' option.
qemu as client can manage either style since 2.6.0, commit 69b49502d8
For comparison:
nbd 3.10 dropped oldstyle long ago (Mar 2015):
https://github.
From: Peter Maydell
Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by not using the
"mo
Commit 145614a1 introduced --tls-creds and documented it in
qemu-nbd.texi, but forgot to document it in 'qemu-nbd --help'.
Signed-off-by: Eric Blake
Message-Id: <20181003180426.602765-1-ebl...@redhat.com>
Reviewed-by: John Snow
---
qemu-nbd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/
From: Vladimir Sementsov-Ogievskiy
After the previous commit, nbd_client_new's first parameter is always
NULL. Let's drop it with all corresponding old-style negotiation code
path which is unreachable now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20181003170228.95973-3-vsement..
From: Vladimir Sementsov-Ogievskiy
We should not go to structured-read branch on CACHE command, fix that.
Bug introduced in bc37b06a5cde24 "nbd/server: introduce NBD_CMD_CACHE"
with the whole feature and affects 3.0.0 release.
Signed-off-by: Vladimir Sementsov-Ogievskiy
CC: qemu-sta...@nongnu.
63 matches
Mail list logo
