On 01/22/2013 04:32 PM, 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 is a feature of the SCSI protocol that is used by SSDs to
signal that a given data block is no longer in use by the filesystem and
may be erased.

It makes writing to flash faster. Flash write latency degrades with
time, this prevents it from happening. Keep in mind that this is only
important for sync-write workloads (e.g. Databases, NFS, etc.), not
async-write workloads (file servers, bulk storage). For ZFS this is a
win if you're using a flash-based slog (ZIL) device. You can entirely
side-step this issue (and performance-sensitive applications often do)
by placing the slog onto a device not based on flash, e.g. DDRDrive x1,
ZeusRAM, etc.

As you may know, flash memory cells, by design, cannot be overwritten.
They can only be read (very fast), written when they are empty (called
"programmed", still quite fast) or erased (slow as hell). To implement
overwriting, when a flash controller detects an attempt to overwrite an
already programmed flash cell, it instead holds the write while it
erases the block first (which takes a lot of time), and only then
programs it with the new data.

Before SCSI Unmap (also called TRIM in SATA) filesystems had no way of
talking to the underlying flash memory to tell it that a given block of
data has been freed (e.g. due to a user deleting a file). So sooner or
later, a filesystem used up all empty blocks on the flash device and
essentially every write had to first erase some flash blocks to
complete. This impacts synchronous I/O write latency (e.g. ZIL, sync
database I/O, etc.).

With Unmap, a filesystem can preemptively tell the flash controller that
a given data block is no longer needed and the flash controller can, at
its leisure, pre-erase it. Thus, as long as you have free space on your
filesystem, most, if not all of your writes will be direct program
writes, not erase-program.

zfs-discuss mailing list

Reply via email to