Re: blkif discard attributes

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@citrix.com> wrote:
> > > > On 03/07/14 11:08, Jan Beulich wrote:
> > > >>>>> On 03.07.14 at 11:43, <david.vrabel@citrix.com> 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.
>