On 01/22/13 15:32, Edward Ned Harvey
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
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