[Top][All Lists]

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

Re: [PATCH v5 0/9] block: Add retry for werror=/rerror= mechanism

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v5 0/9] block: Add retry for werror=/rerror= mechanism
Date: Thu, 25 Feb 2021 20:24:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

23.02.2021 16:41, Eric Blake wrote:
On 2/23/21 3:40 AM, Stefan Hajnoczi wrote:
On Fri, Feb 05, 2021 at 06:13:06PM +0800, Jiahui Cen wrote:
This patch series propose to extend the werror=/rerror= mechanism to add
a 'retry' feature. It can automatically retry failed I/O requests on error
without sending error back to guest, and guest can get back running smoothly
when I/O is recovred.

This patch series implements a retry followed by werror/rerror=report
after a timeout. This mechanism could be made more generic (and the code
could be simplified) by removing the new werror/rerror=retry action and
instead implementing the retry/timeout followed by *any* werror=/rerror=
policy chosen by the user.

In other words, if the retry interval is non-zero, retry the request and
check for timeouts. When the timeout is reached, obey the
werror=/rerror= action.

This is more flexible than hard-coding werror=retry to mean retry
timeout followed by werror=report.

For example:


Failed write requests will be retried once a second for 15 seconds.
If the timeout is reached the guest is stopped.

Failed read requests will be retried once a second for 15 seconds. If
the timeout is reached the error is reported to the guest.

You may also want to look at what the NBD block device already
implements for retries, and see if making retry generic to the block
layer in general can do everything already possible in the NBD code, at
which point the NBD code can be simplified.  Vladimir (added in cc) is
the best point of contact there.


There are some specific things for retrying in NBD client code, that may not 
make sense for generic code:

We try to handle not some generic error but tcp connection problems. So

1. We NBD retries we wanted to retry only requests failed due to connection 
   So, if NBD server successfully reply with -EIO to client request, we don't 
retry and just report -EIO.
   Such things can be distinguished only inside NBD driver.

2. Timeout is specific too: we start timer when we detected the connection lost 
for the first time.
   During the specified time all current requests are waiting for reconnect, 
they'll be retried if
   connection established.
   On timeout all current requests (waiting for reconnect) will report failure, 
as well as all further
   requests will report failure immediately (until successful reconnect).

Still, of course, NBD driver is over-complicated by reconnect feature 
(especially with reconnect thread:) and
it would be cool to split some parts to be separate...

Best regards,

reply via email to

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