From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: blkif discard attributes Date: Tue, 15 Jul 2014 12:48:03 -0400 Message-ID: <20140715164803.GC8768@laptop.dumpdata.com> References: <53B5298D020000780001FF48@mail.emea.novell.com> <53B525B4.7080606@citrix.com> <53B547BC0200007800020148@mail.emea.novell.com> <53B52DB9.9000301@citrix.com> <53B54B7E02000078000201AC@mail.emea.novell.com> <20140707184058.GC30717@laptop.dumpdata.com> <1405328875.3087.1.camel@kazak.uk.xensource.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 1X75tj-00043X-6d for xen-devel@lists.xenproject.org; Tue, 15 Jul 2014 16:48:11 +0000 Content-Disposition: inline In-Reply-To: <1405328875.3087.1.camel@kazak.uk.xensource.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: Ian Campbell Cc: xen-devel , Boris Ostrovsky , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Mon, Jul 14, 2014 at 10:07:55AM +0100, Ian Campbell wrote: > On Mon, 2014-07-07 at 14:40 -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Jul 03, 2014 at 11:24:30AM +0100, Jan Beulich wrote: > > > >>> On 03.07.14 at 12:17, wrote: > > > > 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. > > > > > > Hmm, good point. So it's then indeed better to not communicate this. > > > Albeit similar issues arise with the existing attributes we communicate: > > > What if the new backend doesn't satisfy the assumptions on the old > > > one? Possibly the request may get failed, but possibly it may also get > > > executed wrongly. Neither of which is very desirable. > > > > That is OK with discard operations. It is OK if they fail intermediately. > > Are there not security implications to failing a discard? Or do the > interfaces not make that promise to the higher layers? No security implications. The semantics behind a discard (ATA UNMAP or SCSI DISCARD) is that it is a hint to the storage device. If it starts failing, then users can stop issuing the discard operations (or they can continue). > > Ian. >