'compactor' functionality for zvols

[gcooper]

One of the things that was brought up in #freenas is that although we're using thin provisioning with zvols, there isn't a way to compact data and reclaim used space, either via ZFS or via iSCSI.

A user (echorelay) asked that we add the functionality to have feature parity with VMware, etc.

The chat log follows.

22:25 < echorelay> another question for ya - why do not re-gain free space after deleting data?
22:25 < dw5304> the pool size
22:25 < echorelay> do I not *
22:25 < gcooper> echorelay: depends on whether or not you are taking snapshots
22:25 < echorelay> I just built the server today
22:25 < echorelay> no chance to create snapshots
22:26 < gcooper> i honestly have no idea given the info i have so far
22:26 < gcooper> which isn't much TBH
22:26 < echorelay> do you guys have any idea how I CAN get that free space back ?
22:26 < gcooper> again, i have no idea what's 'using' the free space :)
22:27 < dw5304> u sure u dont have any shapshots ?
22:27 < echorelay> well, example, I copied some ISO's over to the iscsi target. Used space increased, free space decreased. I then deleted the ISO, however the free space and used space stayed the same
22:27 < dw5304> ah
22:28 < dw5304> cause windows really dont delete files ;P
22:28 < echorelay> what you mean?
22:28 < dw5304> or not fromwhat i have seen
22:28 < dw5304> on my end
22:28 < dw5304> works the same w/ vhd's
22:28 < gcooper> indeed
22:28 < echorelay> yep, I have seen that with vhd's... but there is a way to reclaim free space
22:28 < echorelay> i've seen that with apple time machine backups too
22:28 < dw5304> gcooper?
22:29 < dw5304> no idea on my end
22:29 < gcooper> well... that's because you have a second app that reclaims space
22:29 < gcooper> 22:28 < dw5304> works the same w/ vhd's
22:29 < gcooper> 22:28 < gcooper> indeed
22:29 < dw5304> no i mean to reclaim
22:29 < dw5304> :P
22:29 < dw5304> like u can do w/ the vhd compactor
22:29 < dw5304> app
22:29 < echorelay> ^^ this is what I am referring too
22:29 < dw5304> disk degrage
22:30 < dw5304> then compact the --
22:30 < dw5304> 00
22:30 < dw5304> 00's
22:30 < echorelay> there is no "compactor" within freenas
22:30 < echorelay> as far as I can tell
22:30 < gcooper> if there was one, it would need to be between istgt and zfs
22:31 < echorelay> wasn't sure what "scrub volume" was so I clicked that and it didn't do anything either
22:31 < gcooper> i can say based on the former, it probably doesn't exist :)
22:31 < echorelay> gcooper: so what do you do when you fill up your volumes?
22:31 < dw5304> lol well theres something that needs to be created then :P
22:31 < gcooper> echorelay: delete?
22:31 < gcooper> but that's a very good question i suppose
22:31 < echorelay> I have, thats just it. I delete files, but the free space isn't regained
22:32 < gcooper> i'll raise it on the support tracker
22:32 < echorelay> you mean delete the volumes?

[gcooper]

Before someone says "turn on dedup/compression!", here's some relevant discussion for this issue: ​http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/35630 , in particular I already know that dedup in several scenarios can be a really bad idea if the storage server is slow enough or not built out to the point where it can handle deduping the user requested amount of storage. Unfortunately according to reports in the above thread, it appears that data isn't actively compressed across the wire with zfs send/recv (although, using ssh -C with compression enabled on the remote end might do the trick at the cost of a few more CPU cycles), and data is decompressed on the receiving side, if compression isn't already enabled on the remote target dataset.

For our intents and purposes, it just seems like there should be a more easy-to-follow recipe/procedure for solving this via the GUI or via another similar tie-in. Documentation for now and a corresponding plugin for later would be ok.