[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines |
Date: |
Tue, 8 Sep 2015 12:07:17 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, (continued)
- Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Denis V. Lunev, 2015/09/08
- Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Fam Zheng, 2015/09/08
- Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Denis V. Lunev, 2015/09/08
- Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Kevin Wolf, 2015/09/08
- Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Fam Zheng, 2015/09/08
Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Paolo Bonzini, 2015/09/08
Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines,
Kevin Wolf <=
Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, Stefan Hajnoczi, 2015/09/08
Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines, John Snow, 2015/09/08
[Qemu-devel] Summary: [PATCH RFC 0/5] disk deadlines, Denis V. Lunev, 2015/09/10