IN THIS EDITION
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!
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:
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!
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. Contact Jeremy Wolfe at (720) 249-2641 today to schedule your own custom training session!
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?” 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:
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 actionsDo not use:
Test SetupDo not use:
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 Webex 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: 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.
|
|