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: [email protected] > To: [email protected] > 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 > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
