From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 2 of 3] interface: Flesh out the BLKIF_OP_DISCARD description Date: Thu, 13 Oct 2011 11:04:07 -0400 Message-ID: <20111013150407.GC9820@phenom.oracle.com> References: <15c2d70dbac3e31c2d74.1318457567@localhost6.localdomain6> <1318492807.21903.789.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1318492807.21903.789.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , "JBeulich@suse.com" List-Id: xen-devel@lists.xenproject.org On Thu, Oct 13, 2011 at 09:00:07AM +0100, Ian Campbell wrote: > Thanks for splitting these out. > > On Wed, 2011-10-12 at 23:12 +0100, Konrad Rzeszutek Wilk wrote: > [...] > > + * The backend can optionally provide two extra XenBus attributes to > > + * further optimize the discard functionality: > > + * 'discard-aligment' - Devices that support discard functionality may > > + * internally allocate space in units that are bigger than the exported > > + * logical block size. The discard-alignment parameter indicates how many bytes > > + * the beginning of the partition is offset from the internal allocation unit's > > + * natural alignment. > > So this is to account for the case where a physical device can discard > e.g. 128K blocks at a time but the VBD (a better term than "partition" > in the context, I think) starts at e.g. offset 64K within that > underlying device? > > Does this mean that the virtual device can discard the first 64K (and > thereafter in 128K chunks), or that it cannot because that would overlap [edit: I don't think I answered this question] Yes. > the first 64K of that block which belongs to something else? Or that it > can try but it may or may not succeed. What about if the secure flag is