From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFq0-0001yK-8V for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:09:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZFpv-0001m9-7J for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:09:16 -0400 Received: from relay.parallels.com ([195.214.232.42]:51380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFpu-0001lw-WD for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:09:11 -0400 References: <1441699228-25767-1-git-send-email-den@openvz.org> <55EEAB55.2070908@redhat.com> <20150908100717.GA4230@noname.redhat.com> From: "Denis V. Lunev" Message-ID: <55EEB3BA.1090403@openvz.org> Date: Tue, 8 Sep 2015 13:08:58 +0300 MIME-Version: 1.0 In-Reply-To: <20150908100717.GA4230@noname.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Paolo Bonzini Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , Raushaniya Maksudova On 09/08/2015 01:07 PM, Kevin Wolf wrote: > 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). exactly. VM is paused until IO will be finally completed. > 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