nbd: trace long NBD operations

At the moment there are 2 sources of lengthy operations if configured:
* open connection, which could retry inside and
* reconnect of already opened connection
These operations could be quite lengthy and cumbersome to catch thus
it would be quite natural to add trace points for them.

This patch is based on the original downstream work made by Vladimir.

Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
CC: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
This commit is contained in:
Denis V. Lunev 2022-05-30 12:39:29 +02:00 committed by Vladimir Sementsov-Ogievskiy
parent 9d05a87b77
commit 8bb100c9e2
4 changed files with 12 additions and 1 deletions

View file

@ -371,6 +371,7 @@ static bool nbd_client_connecting(BDRVNBDState *s)
/* Called with s->requests_lock taken. */
static coroutine_fn void nbd_reconnect_attempt(BDRVNBDState *s)
{
int ret;
bool blocking = s->state == NBD_CLIENT_CONNECTING_WAIT;
/*
@ -380,6 +381,8 @@ static coroutine_fn void nbd_reconnect_attempt(BDRVNBDState *s)
assert(nbd_client_connecting(s));
assert(s->in_flight == 1);
trace_nbd_reconnect_attempt(s->bs->in_flight);
if (blocking && !s->reconnect_delay_timer) {
/*
* It's the first reconnect attempt after switching to
@ -401,7 +404,8 @@ static coroutine_fn void nbd_reconnect_attempt(BDRVNBDState *s)
}
qemu_mutex_unlock(&s->requests_lock);
nbd_co_do_establish_connection(s->bs, blocking, NULL);
ret = nbd_co_do_establish_connection(s->bs, blocking, NULL);
trace_nbd_reconnect_attempt_result(ret, s->bs->in_flight);
qemu_mutex_lock(&s->requests_lock);
/*