1. Updated SATA SMART attribute definitions
2. Buffer File Operations->Read File
   Determines the size of the file being read and adjusts the Data Size setting automatically
3. Centers the main window on start
4. Updated SMART and IDENTIFY information to include all ACS-4 changes
5. Fixed spelling errors in SMART and IDENTIFY functions
6. When double-click on a SATA drive display SATA Reallocated & Pending Blocks
   
7. Updated SATA LOGs to current specification (ACS-4)
   Example: -Power Conditions
   
   
   SATA PHY Counters
   
   
   Device Statistics
   
   

1. Added Recover SE Locked Drive to Disk->Data Functions
   
   Will indicate whether or not a drive is locked or has a password assigned
   
   
   Lets you specify a password and indicate if it is the Master or the User password.
   
   The password is needed for both the clear password and the unlock operations.
   
   Click Erase Password to clear the selected password.
   
   Click Unlock Drive to unlock a locked drive.
   
   Note: You have to know what the password was that was assigned to the drive. There is no way to recover what the password is from a drive.
   
   

2. Added SANITIZE functions to Disk->Data Functions
   
   
   
   
   SANITIZE is a new disk purge function being implemented by disk drive manufacturers. It is described in the T10.org SCSI Block Command (SBC-4) document – here is the introduction From Working Draft SCSI Block Commands – 4 (SBC-4) 39

   4.11 Sanitize operations
   
   4.11.1 Sanitize operations overview
   
   A sanitize operation causes the device server to:
   • affect the information on the logical unit’s medium such that recovery of logical block data from the medium is not possible;
   • affect the information in the cache by a method that is outside the scope of this standard such that previously existing data in cache is unable to be accessed; and
   • prevent future access by an application client to cache or medium where the device server is unable to alter the information.
   One of the following sanitize operations may be requested on the logical unit’s medium:
   • a sanitize overwrite operation that causes the device server to alter information by writing a data pattern to the medium one or more times;
   • a sanitize block erase operation that causes the device server to alter information by setting the physical blocks to a vendor specific value; or
   • a sanitize cryptographic erase operation that causes the device server to change encryption keys to prevent correct decryption of previously stored information, which may cause protection information, if any, to be indeterminate.
   All sanitize operations shall be performed on:
   • the medium that is being used to store logical block data;
   • the medium that is not being used to store logical block data (e.g., areas previously used to store logical block data, areas available for allocation, and physical blocks that have become inaccessible);
   and
   • all cache.
   
   An application client requests that the device server perform a sanitize operation using the SANITIZE command (see 5.24).
   
   While the medium is write protected (see 4.12) the device server shall terminate a SANITIZE command with CHECK CONDITION status with the sense key set to DATA PROTECT and the appropriate additional sense code for the condition.
   
   4.11.2 Performing a sanitize operation
   
   Before performing a sanitize operation, the device server shall:
   • terminate all commands in all task sets except INQUIRY commands, REPORT LUNS commands, LOG SENSE commands that specify the Temperature log page (see SPC-4), and REQUEST SENSE commands with CHECK CONDITION status with the sense key set to NOT READY, the additional sense code set to LOGICAL UNIT NOT READY, SANITIZE IN PROGRESS, and the PROGRESS INDICATION field in the sense data set to indicate that the sanitize operation is beginning;
   • stop all enabled power condition timers (see SPC-4);
   • stop all timers for enabled background scan operations (see 4.24);
   • stop all timers or counters enabled for device specific background functions and
   • discard partially downloaded microcode, if any.
   
   While performing a sanitize operation, the device server shall:
   • process INQUIRY commands, REPORT LUNS commands, LOG SENSE commands that specify the Temperature log page (see SPC-4), and REQUEST SENSE commands and terminate all other commands with CHECK CONDITION status with the sense key set to NOT READY, the additional sense code set to LOGICAL UNIT NOT READY, SANITIZE IN PROGRESS, and the PROGRESSINDICATION field in the sense data set to indicate the progress of the sanitize operation;
   • provide pollable sense data (see SPC-4) with the sense key set to NOT READY, the additional sense code set to LOGICAL UNIT NOT READY, SANITIZE IN PROGRESS, and the PROGRESS INDICATION field set to indicate the progress of the sanitize operation;
   • suspend the sanitize operation while processing the following conditions (see SAM-5):
     • a power on;
     • a hard reset;
     • a logical unit reset; or
     • a power loss expected;
   • not suspend the sanitize operation while processing an I_T nexus loss;
   • resume performing the sanitize operation after processing:
     • a logical unit reset; or
     • a power loss expected condition in which no power loss occurs within constraints defined by the applicable SCSI transport protocol standard (e.g., power loss timeout in SPL-3);
   • process task management functions without affecting the processing of the sanitize operation (e.g., an ABORT TASK task management function aborts the SANITIZE command and has no effect on performing the sanitize operation);
   • not alter mode data, INQUIRY data, or READ CAPACITY (16) parameter data (e.g., the number of logical blocks, logical block length, or protection information settings for the logical unit); and
   • identify inaccessible physical blocks and in a vendor specific manner prevent future access to these blocks following a successful sanitize operation.
   
   4.11.3 Completing a sanitize operation
   
   If a sanitize operation completes without error, and logical block provisioning management (see 4.7.3) is supported, then:
   • the initial condition for every LBA should be anchored (see 4.7.3.2) or de-allocated (see 4.7.3.3); and
   • read operations and write operations should complete without error.
   If a sanitize operation completes without error and logical block provisioning management is not supported, then:
   • read commands are processed as described in 5.24.2.2, 5.24.2.3, 5.24.2.4, and 5.24.2.5; and
   • write operations should complete without error.
   If the sanitize operation completes with an error in restricted completion mode, then the device server shall:
   • terminate the SANITIZE command being performed, if any (e.g., the IMMED bit was set to zero in the CDB, and the failure occurs before status is returned for the command), with CHECK CONDITION status with the sense key set to MEDIUM ERROR and the additional sense code set to SANITIZE COMMAND FAILED; and
   • until completion of a successful sanitize operation has occurred, terminate all commands, except SANITIZE commands allowed in the restricted completion mode, INQUIRY commands, REPORT LUNS commands, LOG SENSE commands specifying the Temperature log page (see SPC-4), and REQUEST SENSE commands, with CHECK CONDITION status with the sense key set to MEDIUM ERROR and the additional sense code set to SANITIZE COMMAND FAILED.
   If a sanitize operation completes with an error in unrestricted completion mode, then the device server shall:
   • terminate the SANITIZE command being performed, if any (e.g., the   was set to zero in the CDB, and the failure occurs before status is returned for the command), with CHECK CONDITION status with the sense key set to MEDIUM ERROR and the additional sense code set to SANITIZE COMMAND FAILED; and
   • until completion of a successful sanitize operation has occurred, terminate all commands, except SANITIZE commands, INQUIRY commands, REPORT LUNS commands, LOG SENSE commands specifying the Temperature log page (see SPC-4), and REQUEST SENSE commands, with CHECK CONDITION status with the sense key set to MEDIUM ERROR and the additional sense code set to SANITIZE COMMAND FAILED.
   A sanitize operation that completed with error and was cleared with a SANITIZE command with the service action of EXIT FAILURE MODE may have not performed a complete sanitize operation (e.g., this action may enable the recovery of logical block data from the cache and medium for those logical blocks that were not sanitized).
   
   After the sanitize operation completes the device server shall:
   • initialize all enabled timers and counters; and
   • start all enabled timers and counters for power conditions and background functions.
   
   Sanitize
   
   
   If the drive does not support the SANITIZE commands a message will be displayed.
   
   If the drive does support SANITIZE the type of SANITIZE supported will be displayed.
   
   Options
   1. Overwrite – Number of Passes
      Specify the number of full-drive passes used.
   2. Overwrite – Invert
      If checked and if Number of Passes > 1, then on odd-number passes the data pattern will be bit-inverted.
   3. Overwrite – Data Pattern (Hex)
      Specify the first four bytes of the data pattern to use for the overwrite. These four bytes will be replicated to fill one block
      
      Note: the SANITIZE functions are very powerful and do a good job of consolidating and simplifying various ways to purge a drive.
      
      However – you must be aware that a SANITZE operation can not be stopped or interrupted. Other than the Crypto Sanitize, which completes in a few seconds, the Overwrite method will take a very long time to complete. A 4TB drive will take over 10 hours per pass to complete.
      
      The operation can not be stopped – even powering down the drive- as soon as the drive is powered back up it will continue the SANITIZE operation until it is complete.
3. Updated Quick Commands
   
   Several additions have been made to the Quick Commands (right-click on drive) menu –
   
   
   
4. SATA Device Reset
   Issues a DEVICE RESET command to the selected drive. Accessible from the Quick Command (Right-Click) menu.
   
   
5. Quick Drive Profile Test
   Runs the standard Quick Drive Profile test
   
   
6. DST results in View Log Pages – Page 10
   
   All DST log entries are now displayed in the view Log Pages function when the Self-Test Results Pages (Page 0x10) is selected.
   
   
   
7. SATA Feature Set function (ATA/SATA->Commands->View & Set Features) updated–
   Display the current settings of all available FEATURES
   
   
   
8. User Defined CDB – new file functionality
   
   
   For each individual CDB you may now specify & store a file action, to save incoming (DATA IN) data to a file, or to open a file and use its data for outgoing (DATA OUT) data to the drive.
   • Ignore Data
     This choice does nothing with incoming data and simply uses whatever data is in the buffer for outgoing data.
   • Save Data to File
     This choice will save incoming data to the file specified in the File Name: field. Data will be stored as simple binary data. See use of Inc. File Name below.
   • Incr. File Name
     If this option is checked, and you are issuing the CDB multiple times (using the Repeat field), then the file name that the data is stored to will have a number appended to it for each CDB.
     
     For example, if we specify a file name of MyInqData.bin, and repeat the CDB 3 times -
     
     
     These files will be created –
     
     MyInqData.bin – 1st CDB data
     
     MyInqData0.bin – 2nd CDB data
     
     MyInqData2.bin – 3rd CDB data
     
     
     Load Data from File
     
     This choice will load the CDB data buffer from the specified file, using the file data as the DATA OUT payload.
     
     
     
9. Build/Run Script – uses new CDB file functions
   When you specify a user defined CDB in the Build/Run Script the CDB function will have the new DATA-In/Out file functionality.

1. Update all SATA IDENTIFY and SMART data displays to current (ACS-4) specification
2. Change .log file to display “Drive Information” instead of “SATA IDENTIFY”
3. Don’t fail the Drive Information test if drive does not support SATA Self-Test logs.
4. DMM screen size reduced to work with 1024X768 resolution screens
5. Update all Log Page interpretations to current specification

1. PreTest Actions Tab
   • added Set Mode Pages to Default choice
     
   • Update Capacity = FULL to work with both SCSI/SAS/FC and SATA drives. Restores the factory default capacity to the drive before testing.
     
2. Post-Test Actions Tab
   • added Set Mode Pages to File choice
   • added Set Mode Pages to Default choice
     
3. Test Setup Tab
   • Write/Read Write/Verify Warning
     
   • Purge Test Step
     
     • 3-Pass Method
       • “traditional” DoD-5220 3-Pass overwrite method. Uses WRITESAME commands which allows any number of drives to be purged at the same time – all at full speed.
     • SATA SECURITY Erase (SATA SE)
       • For SATA drives – can run either the Normal or the Extended SECURITY ERASE function
     • SANITIZE
       • The newest Purge commands
         • Crypto
           • For Self-Encrypting Drives (SED) – completes the drive purge in a few seconds
           • Block
           • Overwrite
             • Can do multiple passes with data invert on odd-number passes, user specified data pattern.
   • Generate a Purge Certificate
     • Uses a text template file with variables or tokens which will be filled in at runtime.
     • You can embed the following tokens into these files and the certificate generator will fill the values in at print time.
     • Variables available are:.:

                 %d       prints time and date
                 %v       prints SCSI VENDOR data
                 %p       prints SCSI PRODUCT data
                 %r        prints SCSI VERSION data
                 %s       prints SCSI serial number
                 %a       prints SCSI target address
                 %c       prints capacity
                 %n       prints name of last test run
                 %f        prints a form feed
                 %e       prints test error count
                 %k       prints SCSI Sense information

     For example:

     

     The results of the purge will create a file named with the drive name and s/n –

     

     Here are the contents of that file –

     

• Format Test Step
  Lets you specify Format options -
  • Discard G List
    • Throw out all Grown Defects, then format
  • Disable Certify Pass
    • Skip the certify pass after the format
• D. Drive Self-Test Test Step
  • Logs the DST results to the .log file
    
4. Advanced Options
A. -Multiple Workers

Lets you specify a number of workers or I/O streams. Each worker is a separate thread running the current Test Step against each drive.

For example – setting Number of Workers to 4 will spawn four separate threads for each Test Step – all directing their I/O to the same drive.



B. -Delay Between Commands

Lets you inject delays between commands during testing.

For example – this will cause a 100us delay after every 1,000,000th CDBs



Or you can inject the delay(s) based on time – this will inject a 200us delay every 1,000 us



Or you can choose to have delays injected randomly – either by time or by number of CDBs.



 

5. Quick Test Feature



A pull-down list of your favorite DMM Test Sequences.

Add any Test Sequence to the list

 

6. Add Customer Key Serial Number to DMM .log files



 

• None

DTB New Features

• Add 2TB+ support -Add DiskWrite16 and DiskRead16 api calls Other Files Updated or Changed
• Default.dat updated
• SCSI Command Compliance updated to Version 2.0
• STB Suite 9.1 Reference Manual