From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: blkif discard attributes Date: Thu, 3 Jul 2014 11:17:29 +0100 Message-ID: <53B52DB9.9000301@citrix.com> References: <53B5298D020000780001FF48@mail.emea.novell.com> <53B525B4.7080606@citrix.com> <53B547BC0200007800020148@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X2e58-0001dl-Fu for xen-devel@lists.xenproject.org; Thu, 03 Jul 2014 10:17:34 +0000 In-Reply-To: <53B547BC0200007800020148@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 03/07/14 11:08, Jan Beulich wrote: >>>> On 03.07.14 at 11:43, wrote: >> On 03/07/14 08:59, Jan Beulich wrote: >>> discard_zeroes_data also be communicated from backend to frontend? >> >> Perhaps. But how would you handle a guest that used to have >> discard_zeroes_data but is restored with different storage that no >> longer has this property? > > Don't these attributes gets re-evaluated after restore anyway? I don't see how that helps. What if a discard request was submitted before the suspend, expecting the discard to zero and on restore the requests is queued for the new backend which then might not zero. David