[illumos-Developer] Review --> iSCSI UNMAP support
Garrett D'Amore
garrett at damore.org
Fri Feb 11 07:55:34 PST 2011
On Fri, 2011-02-11 at 07:44 -0800, Sumit Gupta wrote:
>
> I never actually discussed about usefulness or merit or doing unmap
> without refreservation. There is an expectation that unmapped space is
> available for other zpool clients. And thats not a narrow view :) (and
> I am not running in this opinion contest). Thats the default
> implementation of storage arrays you see around.
Do these other arrays both have something akin to refreservation and
support unmap? (And reject unmap in the face of of such a
refreservation?) I'd like to have more information if there is
compelling evidence here.
> I am disappointed that people try to shut you up with harsh personal
> comments instead of understanding and responding to the technical
> points.
What harsh personal comments? I've not seen any personal comments
except that I did indicate that you were espousing one view (and if I've
misrepresented that I apologize) which differed from that of everyone
else who's bothered to chime in so far.
>
> If folks want to enable a certain feature because of its merit, you
> can always add an option to sbd. The implementer of the array (e.g.
> Nexenta) may choose the default (enable that option or not).
For NexentaStor 3.1 (which is still based on 134 + backports +
Nexenta-custom patches), our implementation will not include the
explicit check for refreservation.
For illumos, the idea of a tunable behavior is reasonable, I suppose,
but we would still need to agree on a default setting for that tunable.
FWIW, its really unfortunate that modern T10 specs require an extra
level of payment/membership to access.
- Garrett
> Sumit
>
> -----Original Message-----
> From: Garrett D'Amore [mailto:garrett at damore.org]
> Sent: Fri 2/11/2011 6:23 AM
> To: Mike La Spina
> Cc: Sumit Gupta; Bill Sommerfeld; developer at lists.illumos.org
> Subject: RE: [illumos-Developer] Review --> iSCSI UNMAP support
>
> 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
>
>
>
>
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
More information about the Developer
mailing list