From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: blkif discard attributes Date: Thu, 3 Jul 2014 10:43:16 +0100 Message-ID: <53B525B4.7080606@citrix.com> References: <53B5298D020000780001FF48@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 1X2dYP-0006vt-66 for xen-devel@lists.xenproject.org; Thu, 03 Jul 2014 09:43:45 +0000 In-Reply-To: <53B5298D020000780001FF48@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 , Boris Ostrovsky , Konrad Rzeszutek Wilk Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 03/07/14 08:59, Jan Beulich wrote: > All (short of there being a specific blkfront/blkback maintainer), > > it just occurred to me - shouldn't Linux'es max_discard_sectors and The backend could split oversized discard requests into several smaller ones. > 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? David