March 2008

Have you even needed to read a particular block or two from a disk drive? For example, to confirm that your custom test application is really writing the data pattern that you think it is?

A new feature that will be included in the STB Suite 7.2 release is the Buffer->to/from Disk function.

This screen shot shows the simplicity of this function – just go into the Buffer menu and choose File Operations. The new Disk Operations choice highlighted below gives you direct Disk read/write operations:

Simply choose whether you want to read from the disk or write the buffer to the disk. Specify the block number and how many blocks to read/write – and that’s it!

New test methodologies in Disk Manufacturing & Screeing Module(DMM)

The next version of the STB Suite will include new disk test methodologies which can be included as DMM test steps.

These new test methods replicate real-world storage environments, allowing you to focus testing on critical and complex performance areas.

The new tests include:

OLTP (Online Transaction Processing) simulation,

File Server simulation,

Web Server simulation, and

Workstation simulation

Each of these tests simulates the mixture of random and sequential block accesses, along with the mixture or ratio of Write to Read operations, reporting real-world performance metrics, along with stimulating real-world environmental concerns, such as enclosure vibration and power supply loads.

Be sure that your Performa coverage is current so you will have access to these powerful new disk test tools coming next month!

Hands-on training with a STB expert!Here is a list of some recent customer training sessions that STB has conducted – live, interactive web sessions presented by STB programmers:

Three stages of disk drive screening

How to troubleshoot tape drive problems

RAID issues in disk drive testing

Do you have questions about how to best use the STB Suite in your business? STB is happy to work with you in an interactive “live” environment to help you get the most out of your Toolbox. The cost? If you are a current Performa customer it is free! The commitment? Training sessions run between 30 and 60 minutes.

Q. “It seems there are some tests and commands that always fail on SATA drives. Can you explain why this is, and provide a list of things to avoid when testing SATA?”A. “You are absolutely correct – for all their similarities there are some important differences between SATA drives and their SAS/SCSI/FC cousins.”

This is because in the storage marketplace SATA drives evolved upward from earlier ATA drives, incorporating the basic functionality (reading and writing data) of the more intelligent SCSI drives, but for economic reasons leaving some of the more advanced features out.

In order for SATA drives to be easily integrated into existing systems most SCSI commands are mapped to ATA commands and the data is manipulated to be returned as it would be from a SCSI command. Some of these mappings work in a straight forward way, while others can be unpredictable. A good example of this is the SCSI INQUIRY command. This command is not directly implemented in SATA – SATA uses a different command called IDENTIFY DEVICE, which returns mostly the same data as SCSI INQUIRY, but in a different format. Somewhere along the line of operating system, drivers, controllers, and drives the INQUIRY command gets mapped to the IDENTIFY DEVICE command and the returned data is massaged to make it appear as if it is “real” SCSI INQUIRY data.

Other SCSI commands are not implemented or mapped at all. For instance, SCSI/SAS/FC drives have MODE PAGES which can be modified to change parameters that can affect drive performance in different applications – allowing a drive to be “tuned” for maximum performance in a given situation. SATA drives to not have MODE PAGES.

Here is a list of COMMANDS and operations which are NOT supported on SATA drives:

MODE SENSE (reading MODE PAGES)

MODE SELECT (writing MODE PAGES)

READ DEFECT DATA – you can’t see a list of defects on a SATA drive

LOG SENSE (reading LOG PAGES)

LOG SELECT (writing LOG PAGES)

WRITE/VERIFY

VERIFY

Changing block size

Downloading firmware

FORMAT

A complete list of SATA commands is shown at the bottom of this article, and we advise you reading the most current ATA 7 command specifications found at http://www.t13.org/ to gain a thorough understanding of the inner workings of ATA/SATA drives.

In the meantime be aware that issuing any of these non-implemented commands may cause the drive to fail the command, which in the case of a test scenario could abort the test. Therefore you will want to avoid issuing non-implemented or non-mapped commands.

In particular, when using Disk Manufacturing Module (DMM) to test SATA drives do not include any test steps which use non-implemented commands. For instance, do not have a test step to record the Grown Defect List. Do not use the Clear Log Pages pre-test steps. Instead of having a test step to do a WRITE/VERIFY do a WRITE/READ step, or an individual WRITE and individual READS step. Do not try to change the block size or low-level format the drive.

Specifically – do not do any of the following in your DMM disk tests when testing SATA drives:

Pre-Test actions

Do not use:

Change firmware

Change block size

Change capacity

Fail on p Defects

Fail on G Defects

Set Mode pages using file

Clear Log Pages

Save Mode Pages to Database

Test Setup

Do not use:

Write/Verify

FW Download

Seek

Format

P List, G List

Clear Log Pages

Also be aware that some SATA controller/drive configurations will only allow 64K byte data transfers.

Summary:

Learning the differences between testing SATA drives and SCSI drives is important. If you need specific help setting up your SATA test environment please use your valuable Performa Support resource. Email us, phone us, or schedule a live web support session with STB developers – and we will be happy to help you set up a thorough SATA test environment.

ATA/SATA command codes

Using BAM to diagnose a problem

The Problem: A system has two libraries, one with 36 mailboxes and the other with no mailboxes. An application designed to show the contents of a library (i.e. number of drives, storage cells, mechanical arms, and mailboxes) was correctly showing the first library as having 36 mailboxes but was also showing the second library (which has no mailboxes) as having 36 mailboxes.

Using BAM: The designer of the application knew that it was issuing the “Read Element Status” library command to retrieve mailbox information. So the designer used BAM to determine exactly what information the second library was returning for mailbox information. The BAM trace is below:

In the above BAM trace, the library returns “all zeroes” when returning “mailbox information”. This “all zeroes” indicates there is no mailbox information (as it should since this particular library has no mailboxes).

The Solution: The BAM trace confirms to the designer that the library is in fact returning correct and valid mailbox information. Since the designer’s application is reporting many mailboxes, the designer knows the error is in his software. A detailed analysis of the software indicated library information was stored in multiple locations, and one of these locations had the mailbox information of the other library (the one with 36 mailboxes). The mailbox information was NOT updated with the correct information due to the fact there wasn’t any mailbox information, leading to the incorrect display.

SCSItoolbox Suite version 7.2 Release Notes

In our next release of the SCSItoolbox Suite version 7.2 will be available to our Active Performa customers come April 15th! So if you’ve been waiting to upgrade your old STB license, now is a great time. To read the Release notes for this version please view them online here. To renew your Performa coverage you can contact sales at 720.249.2641 or purchase online at save 10%! Buy Now