On 2013-02-10 10:57, Datnus wrote:
I run dd if=/dev/zero of=testfile bs=1024k count=50000 inside the iscsi vmfs
from ESXi and rm textfile.

However, the zpool list doesn't decrease at all. In fact, the used storage
increase when I do dd.

FreeNas 8.0.4 and ESXi 5.0

Did you also enable compression (any non-"off" kind) for the ZVOL
which houses your iSCSI volume?

The procedure with zero-copying does allocate (logically) the blocks
requested in the sparse volume. If this volume is stored on ZFS with
compression (active at the moment when you write these blocks), then
ZFS detects an all-zeroes blocks and uses no space to store it, only
adding a block pointer entry to reference its emptiness. This way you
get some growth in metadata, but none in userdata for the volume.
If by doing this trick you "overwrite" the non-empty but logically
"deleted" blocks in the VM's filesystem housed inside iSCSI in the
ZVOL, then the backend storage should shrink by releasing those
non-empty blocks. Ultimately, if you use snapshots - those released
blocks would be reassigned into the snapshots of the ZVOL; and so in
order to get usable free space on your pool, you'd have to destroy
all those older snapshots (between creation and deletion times of
those no-longer-useful blocks).

If you have reservations about compression for VMs (performance-wise
or somehow else), take a look at "zle" compression mode which should
only reduce consecutive strings of zeroes.

Also I'd reiterate - the compression mode takes effect for blocks
written after the mode was set. For example, if you prefer to store
your datasets generally uncompressed for any reason, then you can
enable a compression mode, zero-fill the VM disk's free space as
you did, and re-disable the compression for the volume for any
further writes. Also note that if you "zfs send" or otherwise copy
the data off the dataset into another (backup one), only the one
compression method last defined for the target dataset would be
applied to the new writes into it - regardless of absence or
presence (and type) of compression on the original dataset.

//Jim Klimov

zfs-discuss mailing list

Reply via email to