From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42128)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1ZZGPv-0007rR-OL
	for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:46:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1ZZGPs-00049f-Cp
	for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:46:23 -0400
Received: from relay.parallels.com ([195.214.232.42]:56152)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1ZZGPs-00049Q-61
	for qemu-devel@nongnu.org; Tue, 08 Sep 2015 06:46:20 -0400
References: <1441699228-25767-1-git-send-email-den@openvz.org>
	<20150908092035.GG24489@ad.nay.redhat.com>
	<20150908101144.GB4230@noname.redhat.com>
	<20150908102021.GA11908@ad.nay.redhat.com>
From: "Denis V. Lunev" <den@openvz.org>
Message-ID: <55EEBC70.9060107@openvz.org>
Date: Tue, 8 Sep 2015 13:46:08 +0300
MIME-Version: 1.0
In-Reply-To: <20150908102021.GA11908@ad.nay.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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Fam Zheng <famz@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, "qemu-block@nongnu.org Raushaniya Maksudova" <rmaksudova@virtuozzo.com>

On 09/08/2015 01:20 PM, Fam Zheng wrote:
> On Tue, 09/08 12:11, Kevin Wolf wrote:
>> Am 08.09.2015 um 11:20 hat Fam Zheng geschrieben:
>>> [Cc'ing qemu-block@nongnu.org]
>>>
>>> On Tue, 09/08 11:00, Denis V. Lunev wrote:
>>>> To avoid such situation this patchset introduces patch per-drive option
>>>> "disk-deadlines=on|off" which is unset by default.
>>> The general idea sounds very nice. Thanks!
>>>
>>> Should we allow user configuration on the timeout?  If so, the option should be
>>> something like "timeout-seconds=0,1,2...".  Also I think we could use werror
>>> and rerror to control the handling policy (whether to ignore/report/stop on
>>> timeout).
>> Yes, I think the timeout needs to be configurable. However, the only
>> action that makes sense is stop. Everything else would be unsafe because
>> the running request could still complete at a later point.
> What if the timeout happens on a quorum child?  The management can replace it
> transparently without stopping the VM.
>
> Fam
I have not though about this at all as we do not use
quorum in our setups. But some sort of management
stuff can be added on top of this for sure.

Den