[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] blkif discard attributes
On Tue, 2014-07-15 at 12:48 -0400, Konrad Rzeszutek Wilk wrote: > 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, <david.vrabel@xxxxxxxxxx> wrote: > > > > > On 03/07/14 11:08, Jan Beulich wrote: > > > > >>>>> On 03.07.14 at 11:43, <david.vrabel@xxxxxxxxxx> 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. OK, great! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |