From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFoC-0008N2-RU for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:07:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZFo9-0001OL-BH for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:07:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFo9-0001Nh-76 for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:07:21 -0400 Date: Tue, 8 Sep 2015 12:07:17 +0200 From: Kevin Wolf Message-ID: <20150908100717.GA4230@noname.redhat.com> References: <1441699228-25767-1-git-send-email-den@openvz.org> <55EEAB55.2070908@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55EEAB55.2070908@redhat.com> Subject: Re: [Qemu-devel] [PATCH RFC 0/5] disk deadlines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Denis V. Lunev" , qemu-devel@nongnu.org, Stefan Hajnoczi , Raushaniya Maksudova 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