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

[Deano]

I agree, any other logic would be a bug imho. 

UNMAP should tell the storage device these block are unused, regardless of
any higher level accounting. This allows many devices a chance to do the
right things (SSDs being an obvious case).

My 2p,
Deano
deano at cloudpixies.com


-----Original Message-----
From: Garrett D'Amore [mailto:garrett at damore.org] 
Sent: 10 February 2011 16:03
To: Eric Schrock
Cc: Dan McDonald; developer at lists.illumos.org
Subject: Re: [illumos-Developer] Review --> iSCSI UNMAP support

I am neither Matt nor George, but your statements here have thoroughly
convinced me at least.  The examples you've given (including the prior
one) are especially relevant.

There's another one though.

When we get UNMAP support in ZFS itself (and sd/SCSA), being able to
pass UNMAP through to underlying storage may yield other performance
benefits, even if you are only planning on using a single zvol on the
pool and have no "storage size" concerns.

	- Garrett

On Thu, 2011-02-10 at 10:56 -0500, Eric Schrock wrote:
> On Thu, Feb 10, 2011 at 10:40 AM, Sumit Gupta
> <Sumit.Gupta at nexenta.com> wrote:
>         
>         
>         A reservation is reservation, whatever the intent is. Reserved
>         space means it cannot be given up. How can we return success
>         to an unmap command if the zpool is still accounting for that
>         much space being in use by the zvol. That will confuse the
>         user. And that space wont be available to other zvols and such
>         which is what the unmap is trying to do. I dont understand the
>         debate.
>         
> 
> 
> The reason for the confusion is that "accounted for != in use" in
> ZFS.  Allocating blocks has real ramifications for snapshots, space
> map usage, and a whole host of other things that come with using
> "real" space.  Freeing blocks will always have a meaningful effect
> even if there is a reservation - that is the ZFS model.  I don't know
> who the user is above or how they'd even know UNMAP was in play, but I
> would expect the USED stat for a zvol to go down on UNMAP, regardless
> of any reservation; I don't see how one could expect anything else.
> 
> 
> I have already provided you one example of where your assumptions are
> wrong and do active harm; here are some more off the top of my head:
> 
> 
>    - If the user later chooses to switch to a sparse zvol, they have
> space they can never reclaim
>    - One may want to create a sparse clone, which would needlessly
> reference extra blocks
>    - A 'zfs send' sends pointless data, and ends up being O(size)
> instead of O(used)
>    - Unused but allocated blocks cause unnecessary space map
> fragmentation, leading to poor performance
> 
> 
> If you can get buy in from Matt or George (the other ZFS approvers)
> I'm happy to defer to them, but IMO this is a bug that needs to be
> fixed.
> 
> 
> Thanks,
> 
> 
>         
> - Eric 
> 
> -- 
> Eric Schrock
> Delphix
> 
> 
> 275 Middlefield Road, Suite 50
> Menlo Park, CA 94025
> http://www.delphix.com
> 
> _______________________________________________
> 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