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

[Garrett D'Amore]

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