blkif discard attributes

blkif discard attributes

[Jan Beulich]

All (short of there being a specific blkfront/blkback maintainer),

it just occurred to me - shouldn't Linux'es max_discard_sectors and
discard_zeroes_data also be communicated from backend to frontend?

Thanks, Jan

Re: blkif discard attributes

[David Vrabel]

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

Re: blkif discard attributes

[Jan Beulich]

>>> 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?

Jan

Re: blkif discard attributes

[David Vrabel]

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.

David

Re: blkif discard attributes

[Jan Beulich]

>>> 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.

Jan

Re: blkif discard attributes

[Konrad Rzeszutek Wilk]

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.
> 
> Jan
> 

Re: blkif discard attributes

[Ian Campbell]

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?

Ian.

Re: blkif discard attributes

[Konrad Rzeszutek Wilk]

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.
> 

Re: blkif discard attributes

[Ian Campbell]

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@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.

OK, great!

Ian.