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

[Randy S]

Hallo Jim,

Yes , this helps me indeed to understand it all !!

Thank you and Ian very much for your responses .

Regards !


> Date: Thu, 7 Feb 2013 11:25:42 +0100
> From: jimklimov at cos.ru
> To: openindiana-discuss at openindiana.org
> Subject: Re: [OpenIndiana-discuss] Question about disk space usage on iSCSI volumes
> 
> 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
> 
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss