On 01/22/13 15:32, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote:
From: Darren J Moffat [mailto:darr...@opensolaris.org]

Support for SCSI UNMAP - both issuing it and honoring it when it is the
backing store of an iSCSI target.

When I search for scsi unmap, I come up with all sorts of documentation that 
... is ... like reading a medical journal when all you want to know is the 
conversion from 98.6F to C.

Would you mind momentarily, describing what SCSI UNMAP is used for?  If I were 
describing to a customer (CEO, CFO) I'm not going to tell them about SCSI 
UNMAP, I'm going to say the new system has a new feature that enables ... or 
solves the ___ problem...

Customer doesn't *necessarily* have to be as clueless as CEO/CFO.  Perhaps just 
another IT person, or whatever.

It is a mechanism for part of the storage system above the "disk" (eg ZFS) to inform the "disk" that it is no longer using a given set of blocks.

This is useful when using an SSD - see Saso's excellent response on that.

However it can also be very useful when your "disk" is an iSCSI LUN. It allows the filesystem layer (eg ZFS or NTFS, etc) when on iSCSI LUN that advertises SCSI UNMAP to tell the target there are blocks in that LUN it isn't using any more (eg it just deleted some blocks).

This means you can get more accurate space usage when using things like iSCSI.

ZFS in Solaris 11.1 issues SCSI UNMAP to devices that support it and the ZVOLs when exported over COMSTAR advertise it too.

In the iSCSI case it is mostly about improved space accounting and utilisation. This is particularly interesting with ZFS when snapshots and clones of ZVOLs come into play.

Some vendors call this (and thins like it) "Thin Provisioning", I'd say it is more "accurate communication between 'disk' and filesystem" about in use blocks.

Darren J Moffat
zfs-discuss mailing list

Reply via email to