Content

This article applies to the following hardware, when running V8.1.0 or later software:

• SAN Volume Controller
• IBM Storwize V5000, V5000E, V5100, V7000
• IBM FlashSystem 5000, 5100, 7200, 9100, 9200, 9200R and V9000

What is SCSI Unmap?

Hosts can issue SCSI Unmap commands to storage controllers, to indicate that an LBA range on a disk can be freed. This might happen, for example, when formatting a new volume, or deleting files in a filesystem.

When a Spectrum Virtualize system running V8.1.0 or later receives a SCSI Unmap command, it overwrites the relevant region of the volume with all-zero data. This allows thin-provisioned storage controllers (such as IBM FlashSystem A9000 and IBM FlashSystem 900 model AE3) to reclaim physical capacity through garbage collection.

The main benefit is that this helps prevent a thin-provisioning storage controller from running out of free capacity for write I/O requests. This means, when using these controllers, SCSI Unmap should normally be left enabled.

One possible issue is that, with lower-performing storage such as Nearline arrays, extra I/O workload can be generated which can increase response times. See below for further details.

Which software versions support SCSI Unmap?

• V8.1.0 supports SCSI Unmap commands from the host.
  Host Unmap commands will result in data being zeroed, but will not increase the free capacity reported by the storage pool.
   
• V8.1.1 (and later) can also generate SCSI Unmap commands to specific backend storage controllers and drives.
  This occurs when vdisks are deleted, extents are migrated, or an Unmap command is received from the host. Host Unmap commands will not increase the free capacity reported by a standard pool, but they will increase the free physical capacity in an FCM array.
  
  SCSI Unmap commands are only sent to the following external storage controllers:
  • IBM Storwize and FlashSystem controllers (excluding FlashSystem 840 and FlashSystem 900 model AE2), and A9000
  • Pure storage systems.
  • HPE Nimble controllers (when the IBM system is running 8.3.0.1 or later software)
  • Infinidat Infinibox controllers (when the IBM system is running 8.4.0.2 or later software)
  • Hitachi controllers (when the IBM system is running 8.4.0.7, 8.5.0.5, 8.5.2.0 or later software)
  • Dell EMC PowerStore and PowerMax controllers (when the IBM system is running 8.4.0.7, 8.5.0.5, 8.5.2.0 or later software).
• SCSI Unmap commands are also sent to internal FlashCore Modules (FCMs) in order to free physical capacity. This applies whether the FCM array is in a standard pool or a Data Reduction Pool.
   
• V8.1.2 and later can also reclaim capacity in a Data Reduction Pool, when a host issues SCSI Unmap commands.
  Host Unmap commands can increase the free capacity reported by the Data Reduction Pool, when received by thin-provisioned or compressed volumes. This does not apply to standard storage pools.
   
• V8.2.1 and later support SCSI Unmap on VMWare VVols
  Note: Earlier versions of software will not accept SCSI Unmap commands for VMWare VVols, even if host unmap support is enabled at a system level.
  
  V8.2.1 also introduces the ability to enable or disable host unmap independently from backend storage controller unmap.
   

What will change after upgrading to V8.1.0 or later?

After upgrading from pre-8.1.0 to 8.1.x, or from 8.1.x to 8.2.x: SCSI Unmap support will be enabled by default.

After upgrade from pre-8.1.0 to 8.2.1 or later: Backend storage SCSI Unmap support will be enabled, but host SCSI Unmap support will be disabled by default.

If host SCSI Unmap support is enabled, the Spectrum Virtualize system will advertise support for SCSI Unmap to hosts.

Some host types (for example, Windows and Linux) will then change their behaviour when creating a new filesystem on a volume, issuing SCSI Unmap commands to the whole capacity of the volume. This causes the system to overwrite the whole capacity with zero-data - and the format will complete when all of these writes have completed.

Some host types run a background process (for example fstrim on Linux), which periodically issues SCSI Unmap commands for regions of a filesystem that are no longer required.

This means:

• Formatting time is likely to increase, compared with pre-V8.1 software which did not support the SCSI Unmap command.
• Background processes like fstrim may periodically issue large numbers of Unmap commands
• Host SCSI Unmap commands will drive additional I/O workload to backend storage. In some circumstances (for example, volumes located on a heavily-loaded nearline SAS array) this can cause an increase in response times on volumes using the same storage. Spectrum Control or other performance monitoring software can alert the user if this occurs.

VMware limits the SCSI Unmap workload that is submitted to a volume, which reduces the likelihood of storage being overloaded.

How can storage performance impact be prevented?

If performance monitoring indicates that SCSI Unmap workload is impacting performance, consider taking the following steps:

1. Run V8.1.1.2 or later

V8.1.1.2 introduced performance optimizations which can reduce the performance impact. For example, SCSI Unmap commands received while Spectrum Virtualize is formatting a volume will be handled without requiring additional I/O to the backend storage.

2. Use Spectrum Virtualize offload throttling to reduce the rate of SCSI Unmaps being processed

The rate of offload commands (including SCSI Unmap, XCOPY and WRITESAME) which will be accepted from the host can be limited by setting an offload throttle. Refer to the Knowledge Center for further details:

https://www.ibm.com/docs/en/flashsystem-7x00/8.4.x?topic=administering-managing-throttle-offload-io

Setting an offload throttle can help reduce the load on backend storage, but this can also increase the total time taken for completion of host SCSI Unmap commands (for example, this may increase the time taken to format volumes on a Windows host). 

How can SCSI Unmap be disabled?

If formatting time becomes a problem, or if host SCSI Unmap requests trigger performance issues, it may be desirable to disable SCSI Unmap support. There are three ways to do this.

Note: Before using either option 2 or option 3, it is recommended to upgrade to V8.1.1.2, V8.1.3.0 or a later release. Some host types do not tolerate concurrently disabling SCSI Unmap on earlier code levels, requiring a host reboot to complete the change.

1. Disable SCSI Unmap by reconfiguring the host.

Host operating systems have different mechanisms for disabling SCSI Unmap / TRIM commands on a volume. Refer to the host documentation for full details.

On Linux, mounting a filesystem with "-o nodiscard" will disable SCSI Unmap

2. Change the host type to generic_no_unmap

If the host type is generic, change it to generic_no_unmap by issuing the following CLI command:

svctask chhost -type generic_no_unmap <host_id_or_name>

To re-enable SCSI Unmap for the host, change the host type back to generic.

If the host type is NOT generic (for example, HPUX or adminlun/VVOLS), SCSI Unmap cannot be disabled for that individual host.

3. Disable SCSI Unmap for the whole Spectrum Virtualize system

This is not recommended if:

• the system is virtualizing a thin-provisioned storage controller, or
• Data Reduction Pools are being used on 8.1.2 or later software.

In these circumstances, disabling SCSI Unmap will increase the amount of physical capacity that is used, and make it more likely that the storage will run out of free capacity.

SCSI Unmap can be disabled using the CLI command:

svctask chsystem -unmap off

To re-enable SCSI Unmap, use the "-unmap on" option.

Disabling SCSI Unmap will prevent the system from advertising support to hosts, as well as preventing Unmap from being sent to backend storage controllers.