On 07/03/2018 08:46 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
before v4 realization, I'd like to discuss some questions.
Our proposal for v4 is the following:
1. don't reconnect on nbd_open. So, on open we do only one connect
attempt, and if it fails, open fails.
2. don't configure timeout between attempts. instead do the following:
1s timeout, then 2s, then 4, 8, 16, and then always 16 until success
3. configure only time, after disconnect, during which requests are
paused (and after this time, if not connected, they will return EIO). Or
not configure it for now, make a default of 5 minutes.
Any ideas?
I apologize that I haven't had time to review this series closely. At
this point, I think it's missed 3.0, and will have to be 3.1 material.
Your proposal for exponential backoff on reconnect attempts makes sense;
beyond that, I haven't reviewed closely enough to know if I have other
suggestions on how many knobs to expose to the user, vs. how much to
make automatic.
09.06.2018 18:32, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
Here is NBD reconnect.
The feature realized inside nbd-client driver and works as follows:
There are two parameters: reconnect-attempts and reconnect-timeout.
So, we will try to reconnect in case of initial connection failed or
in case of connection lost. All current and new io operations will wait
until we make reconnect-attempts tries to reconnect. After this, all
requests will fail with EIO, but we will continue trying to reconnect.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
