qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2 3/6] qapi: add nbd-server-remove


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH v2 3/6] qapi: add nbd-server-remove
Date: Mon, 15 Jan 2018 20:47:41 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

15.01.2018 18:09, Eric Blake wrote:
On 01/12/2018 03:47 AM, Vladimir Sementsov-Ogievskiy wrote:
09.01.2018 22:52, Eric Blake wrote:
On 12/07/2017 09:50 AM, Vladimir Sementsov-Ogievskiy wrote:
Add command for export removing. It is needed for cases when we
don't want to keep export after the operation on it was completed.
The other example is temporary node, created with blockdev-add.
If we want to delete it we should firstly remove corresponding
NBD export.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
---
Do we want a third mode in the middle, where the server starts replying
to all existing clients with ESHUTDOWN errors for all new requests
rather than abruptly disconnecting (no new I/O, but no forced disconnect
and pending in-flight transactions can still complete gracefully)?
looks interesting. what about the following naming?

@mode: possible values:
               hide - just hide server from new clients, maintain
existing connections,
                           remove after all clients disconnected
               soft - like hide, but answer with ESHUTDOWN for all
further requests from
                           existing connections
               hard - hard disconnect all clients and remove server
               (default: soft)
Or even a fourth mode that causes an immediate error return without
state change if there are any connected clients, but otherwise removes
the server.

new corresponding states of nbd export:
hidden, shutting_down

and we allow transitions:

normal_execution -> hidden
normal_execution -> shutting_down
normal_execution -> exit
hidden -> shutting_down
hidden -> exit
shutting_down -> exit
Seems reasonable.  Are you planning on tackling a respin of this series
incorporating that idea?


yes, will do.


--
Best regards,
Vladimir




reply via email to

[Prev in Thread] Current Thread [Next in Thread]