From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFRZ-0008Kz-Q4 for qemu-devel@nongnu.org; Tue, 08 Sep 2015 05:44:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZFRV-0008LC-Qq for qemu-devel@nongnu.org; Tue, 08 Sep 2015 05:44:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFRV-0008L8-Ma for qemu-devel@nongnu.org; Tue, 08 Sep 2015 05:43:57 -0400 References: <1441699228-25767-1-git-send-email-den@openvz.org> <55EEAB55.2070908@redhat.com> <55EEAD4B.6090609@openvz.org> From: Paolo Bonzini Message-ID: <55EEADD9.6010008@redhat.com> Date: Tue, 8 Sep 2015 11:43:53 +0200 MIME-Version: 1.0 In-Reply-To: <55EEAD4B.6090609@openvz.org> Content-Type: text/plain; charset=windows-1252 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: "Denis V. Lunev" Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , Raushaniya Maksudova On 08/09/2015 11:41, Denis V. Lunev wrote: > This solution is far not perfect as there is a race window for > request complete anyway. Though the amount of failures is > reduced by 2-3 orders of magnitude. > > The behavior is similar not for soft mounts, which could > corrupt the data but to hard mounts which are default AFAIR. > It will not corrupt the data and should patiently wait > request complete. > > Without the disk the guest is not able to serve any request and > thus keeping it running does not make serious sense. > > This approach is used by Odin in production for years and > we were able to seriously reduce the amount of end-user > reclamations. We were unable to invent any reasonable > solution without guest modification/timeouts tuning. > > Anyway, this code is off by default, storage agnostic, separated. > Yes, we will be able to maintain it for us out-of-tree, but... I'm not saying the patches are unacceptable, not at all. It just needs a bit of documentation to understand the tradeoffs. I admit I have not even started reading the code. Your experience is very valuable, and it's great that you are contributing it to QEMU and KVM! Paolo