Re: [PATCH v3 0/9] block-backend: Introduce I/O hang

[Stefan Hajnoczi]

On Thu, Oct 22, 2020 at 09:02:54PM +0800, Jiahui Cen wrote:
> A VM in the cloud environment may use a virutal disk as the backend storage,
> and there are usually filesystems on the virtual block device. When backend
> storage is temporarily down, any I/O issued to the virtual block device will
> cause an error. For example, an error occurred in ext4 filesystem would make
> the filesystem readonly. However a cloud backend storage can be soon 
> recovered.
> For example, an IP-SAN may be down due to network failure and will be online
> soon after network is recovered. The error in the filesystem may not be
> recovered unless a device reattach or system restart. So an I/O rehandle is
> in need to implement a self-healing mechanism.
> 
> This patch series propose a feature called I/O hang. It can rehandle AIOs
> with EIO error without sending error back to guest. From guest's perspective
> of view it is just like an IO is hanging and not returned. Guest can get
> back running smoothly when I/O is recovred with this feature enabled.

Hi,
This feature seems like an extension of the existing -drive
rerror=/werror= parameters:

  werror=action,rerror=action
      Specify which action to take on write and read errors. Valid
      actions are: "ignore" (ignore the error and try to continue),
      "stop" (pause QEMU), "report" (report the error to the guest),
      "enospc" (pause QEMU only if the host disk is full; report the
      error to the guest otherwise).  The default setting is
      werror=enospc and rerror=report.

That mechanism already has a list of requests to retry and live
migration integration. Using the werror=/rerror= mechanism would avoid
code duplication between these features. You could add a
werror/rerror=retry error action for this feature.

Does that sound good?

Stefan

signature.asc
Description: PGP signature