[OpenIndiana-discuss] Question about disk space usage on iSCSI volumes

[Jim Klimov]

On 2013-02-07 10:56, Randy S wrote:
>
> Hallo Ian,
>
>
>> Sparse provisioned?
> Yes, does this make a difference when determining free space?
>
> I will test you method.
>
> If the system can recognize that data is being stored (watching the number of "zfs get usedbydataset" grow), you would expect that it can also recognize that data has been deleted, regardless of being copy on write.
> However the usedbydataset does not decrease. If it doesn't decrease ever, what's the use of such an attribute?

The zvols are not transparent to ZFS in terms of space that this
block device's user might think available. For all that ZFS cares,
it securely stores a huge binary blob. It doesn't know what's in
it - a database chunk, an NTFS, FAT or another ZFS structure,
a VM disk image...

So if the internal user marks something as free and does not care
to zero out the used blocks, they still contain an uncompressable
binary white noise. It is just that the internal user chooses to
no longer reference this data - it is still there.

This is what UNMAP is for - the (iSCSI LUN's) user can report that
a range of blocks or bytes is no longer used by it and can now be
repurposed by the backing storage - i.e. reprogramming for flash,
zero-out for zvol, etc.

The trick Ian detailed so nicely does involve compression of the
zvol - so that the zeroes you fill it with would use no storage
on your outside pool. However, from the point of view of that
internal user of the zvol (i.e. a filesystem) you write a file
that requires lots of space, so that FS allows overwriting blocks
that it no longer needs and deemed "deleted".

For uncompressed ZVOLs it should, I guess, honestly store the
zeroes in full-sized blocks. Note that this takes place upon
write of the block, so if you need your zvol's not compressed -
set the attribute, do the zero-fill, and reset the attribute.

And since you mention copy-on-write - remember that if you use
snapshots, the zeroed blocks will be applied to the live copy
of the dataset, while the non-zero blocks will become referenced
by snapshots. And that by default the zvol snapshots extend the
reservations so that the whole zvol may be guaranteed to have
space to be overwritten completely - doubling the reservation
upon first snapshot. You can later modify this, but at a risk
that sometime in the future you might not be able to satisfy
a write request with available space...

HTH,
//Jim