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.
SCSI UNMAP (or SATA TRIM) is a means of telling a storage device that
some blocks are no longer needed. (This might be because a file has been
deleted in the filesystem on the device.)
In the case of a Flash device, it can optimise usage by knowing this,
e.g. it can perhaps perform a background erase on the real blocks so
they're ready for reuse sooner, and/or better optimise wear leveling by
having more spare space to play with. There are some devices in which
this enables the device to improve its lifetime by performing better
wear leveling when having more spare space. It can also help by avoiding
some read-modify-write operations, if the device knows the data that is
in the rest of the 4k block is no loner needed.
In the case of an iSCSI LUN target, these blocks no longer need to be
archived, and if sparse space allocation is in use, the space they
occupied can be freed off. In the particular case of ZFS provisioning
the iSCSI LUN (COMSTAR), you might get performance improvements by
having more free space to play with during other write operations to
allow better storage layout optimisation.
So, bottom line is longer life of SSDs (maybe higher performance too if
there's less waiting for erases during writes), and better space
utilisation and performance for a ZFS COMSTAR target.
--
Andrew Gabriel
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
