[illumos-Developer] Review --> iSCSI UNMAP support

[Garrett D'Amore]

Just to be clear:

The changes to Sumit's code Eric and others have suggested (and which
Dan has now made) don't override refreservation at all.  There was never
a debate about that.

The debate was whether UNMAP should be allowed to proceed at *all* in
the face of such a reservation.  I think so far that everyone apart from
Sumit has agreed that such behavior *is* useful (as it reduces the size
of snapshots, and may offer future performance benefits when we pass
these commands down to underlying storage as UNMAP or TRIM commands),
even though the command won't reduce the amount of storage *reserved*
for use by the data set.

	- Garrett

On Fri, 2011-02-11 at 02:30 -0600, Mike La Spina wrote:
> Garret I agree. 
> 
> ZFS features being set aside I believe that Sumit is correct in the
> method he has chosen.
> The UNMAP SBC command allows the initiator to de-allocate virtual map
> table entries of a sparse enabled store. Therefore it cannot mess with
> the refreserv alloc which is presented outside of this virtual table
> scope. The issue becomes clear when we see that the target has no
> knowledge if a previously mapped block is in use or not (e.g. if an
> initiator zeros all the raw blocks, are they in use?) Only the initiator
> can define this and thus would undesirably control the refreserv state
> if it were allowed to mess with it. 
> UNMAP, WRITE SAME etc are specifically defined to handle the sparse
> table virtual maps on raw block devices from the initiators control
> perspective. So unless the target is a true sparse implementation I
> would exclude them and stick to the T10 SBC command spec scope in this
> case.
> 
> Regards,
> 
> Mike
>  
>          The minimum amount of space guaranteed to a dataset, not
>          including its descendents. When the amount of space used
>          is  below  this  value,  the dataset is treated as if it
>          were  taking  up  the  amount  of  space  specified   by
>          refreservation.   The   refreservation   reservation  is
>          accounted for in the parent datasets  space  used,  and
>          counts  against the parent datasets quotas and reservations.
> 
> -----Original Message-----
> From: Garrett D'Amore [mailto:garrett at damore.org] 
> Sent: Thursday, February 10, 2011 12:10 PM
> To: Sumit Gupta
> Cc: Bill Sommerfeld; developer at lists.illumos.org
> Subject: Re: [illumos-Developer] Review --> iSCSI UNMAP support
> 
> On Thu, 2011-02-10 at 09:43 -0800, Sumit Gupta wrote:
> > 
> > Bill, I understand the zfs side of story. In every reply I gave, I am
> > trying to raise only one very important issue which I feel is not
> > getting addressed. unmap is defined as a part of thin provisioning in
> > SCSI spec (SBC). So there is an expectation that when you unmap some
> > space it goes back to pool so that other pool clients can use it. If
> > you think that point itself is invalid then there is nothing else to
> > discuss on this subject. Otherwise this issue needs to be addressed
> > and without that the implementation is not correct.
> 
> The thing is, with a refreservation is a higher level reservation.  I
> think it represents a ZFS property that exists outside of the scope of
> UNMAP.
> 
> I see valuable uses for UNMAP even in the face of refreservation.  If an
> admin has a reservation, then I think the principle of least surprise is
> that we have to honor that reservation; as others have indicated, UNMAP
> (akin to TRIM in SATA land) offers functionality beyond just
> thin-provisioning.
> 
> All that said, I need to download the relevant T10 specs and read the
> precise wording.
> 
> 	- Garrett
> 
> 
> > 
> > Sumit
> > 
> > -----Original Message-----
> > From: Bill Sommerfeld [mailto:sommerfeld at hamachi.org]
> > Sent: Thu 2/10/2011 8:52 AM
> > To: developer at lists.illumos.org
> > Subject: Re: [illumos-Developer] Review --> iSCSI UNMAP support
> > 
> > On 02/10/11 08:22, Sumit Gupta wrote:
> > > UNMAP-101: If I unmap 1G space then 1G of extra space is available
> > for other zvols. If you are not doing that, then your implementation
> > is wrong.
> > 
> > eric is correct and you are wrong.
> > 
> > reservations in practice can be a hard concept to wrap your brain
> > around
> > -- particularly the interaction between snapshots, refreservations,
> > and
> > pool free space.
> > 
> > if your actual allocated space is equal to your reservation, and you
> > free 1G of space, the pool will ensure that you will be able to use
> > another 1G of space -- if everyone else goes nuts writing until the
> > pool
> > stops them, but you don't use any more space, the pool will keep 1G in
> > reserve for you.
> > 
> > in the mean time, the pool has 1G more room to play with under the
> > covers, which may reduce the amount of fragmentation that all users of
> > the pool may suffer from and generally improve performance.
> > 
> > And it also reduces the size of any snapshots you create from the
> > zvol.
> > 
> >                                                 - Bill
> > 
> > _______________________________________________
> > Developer mailing list
> > Developer at lists.illumos.org
> > http://lists.illumos.org/m/listinfo/developer
> > 
> > 
> > 
> > _______________________________________________
> > Developer mailing list
> > Developer at lists.illumos.org
> > http://lists.illumos.org/m/listinfo/developer
> 
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer