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. TL&DR: 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. THE DETAILS: 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. Cheers, -- Saso _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
