Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines

[Kevin Wolf <kwolf@redhat.com>]

Am 08.09.2015 um 11:33 hat Paolo Bonzini geschrieben:
> 
> 
> On 08/09/2015 10:00, Denis V. Lunev wrote:
> > How the given solution works?
> > 
> > If disk-deadlines option is enabled for a drive, one controls time completion
> > of this drive's requests. The method is as follows (further assume that this
> > option is enabled).
> > 
> > Every drive has its own red-black tree for keeping its requests.
> > Expiration time of the request is a key, cookie (as id of request) is an
> > appropriate node. Assume that every requests has 8 seconds to be completed.
> > If request was not accomplished in time for some reasons (server crash or smth
> > else), timer of this drive is fired and an appropriate callback requests to
> > stop Virtial Machine (VM).
> > 
> > VM remains stopped until all requests from the disk which caused VM's stopping
> > are completed. Furthermore, if there is another disks with 'disk-deadlines=on'
> > whose requests are waiting to be completed, do not start VM : wait completion
> > of all "late" requests from all disks.
> > 
> > Furthermore, all requests which caused VM stopping (or those that just were not
> > completed in time) could be printed using "info disk-deadlines" qemu monitor
> > option as follows:
> 
> This topic has come up several times in the past.
> 
> I agree that the current behavior is not great, but I am not sure that
> timeouts are safe.  For example, how is disk-deadlines=on different from
> NFS soft mounts?

I think the main difference is that it stops the VM and only allows to
continue once the request has completed, either successfully or with a
final failure (if I understand the cover letter correctly, I haven't
looked at the patches yet).

Kevin

> The NFS man page says
> 
>      NB: A so-called "soft" timeout can cause silent data corruption in
>      certain cases.  As such, use the soft option only when client
>      responsiveness is more important than data integrity.  Using NFS
>      over TCP or increasing the value of the retrans option may
>      mitigate some of the risks of using the soft option.
> 
> Note how it only says "mitigate", not solve.
> 
> Paolo