SCSI Toolbox :: Newsletter - February 2003

IN THIS EDITION
Developer Toolbox Announced
Ask Dr. SCSI - Disk Scrubbing
Did you know? - Test Fixed or variable blocks
Did you know? - DTS




Developer Toolbox Announced
SCSI Toolbox is proud to announce our newest product the Developer Toolbox.

The world's most widely used SCSI diagnostic software product is now available in a reference library.

The Developer Toolbox uses our proven interface to access SCSI, Fibre Channel, or ATAPI devices from Visual Basic or C++ running on all 32 bit versions of Windows.

This library can be integrated into all popular test and process development environments such as Visual Basic or Visual C++.

Over 80 functions allow you to easily work with disk drives, tape drives, libraries, and any other SCSI/FC/ATAPI/SATA peripherals! With more tests and functions being added monthly, the Developer Toolbox is a solid and growing test development tool. In use at major manufacturers and integrators, the Developer Toolbox is the proven way to test peripheral storage devices FAST!

The Developer Toolbox also includes its own stand-alone development environment, Scriptwriter Pro. Scriptwriter Pro is a Visual Basic for Applications compatible development environment that includes a debugger/editor, an interpreter/compiler, and a GUI design tool. Complete OLE-aware stand alone applications with graphical user interface can be quickly created with this tool.

Developer Toolbox is $1,295.00, for special introductory pricing and a custom quote please write sales@scsitoolbox.com

For more information on the Developer Toolbox click here:
http://www.scsitoolbox.com/developertoolbox.html






Ask Dr. SCSI

Q. "What are the dangers of doing a partition-only disk scrub?"

A. When trying to scrub a partition on a disk drive you are forced to rely on the operating system to define what the logical block address range of that partition is.

As an simplified example, let’s say you have a partition that is defined as starting at LBA 1,000 and extending to LBA 11,000 as illustrated below:

Partition “A”

LBA
1,000 --------------------------------? 11,000

Now, consider if LBA 5,000 is marked as defective, and is reallocated to Spare Block #1 by the drive, as below:

LBAs                                                     Spare Blocks
                  >->->->->->->->->->->->->->->->->->->->->->-|
                  | |<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-| \|/
1,000--------4,999| | 5,001 ------------------>11,000     /|\ #1

When a software application writes data to this partition, the write to LBA 5,000 actually writes its data into Spare Block 1. This is done transparently by the SCSI drive itself, and cannot be circumvented.

Now, a data-thief obtains access to this computer and in a fairly easy manner either 1) changes LBA 5,000 to no longer be marked as defective, or 2) changes LBA 5,000 to be reallocated to Spare Block #2.

In either case, when a program is run which writes data patterns to this partition, the data that exists in Spare Block #1 is NOT OVERWRITTEN.

Now all the data-thief has to do is to change any LBA on the drive to be reallocated to Spare Block #1, and when that block is read the data will actually be read from Spare Block #1, and they gain access to the secure data.

There is no possible way to remedy this situation without a complete disk scrub that includes a Spare Block scrub.

In summary, a partition “scrub” is not a scrub at all. It is certainly much faster to execute than a real disk scrub, but it is in no way secure.






Did you know? - Test fixed or variable-block records
That the SCSItoolbox tape tests will use either fixed or variable-block records, depending on what type of data has been previously written to the tape. But – you can change it!

Use the Configure Tape choice, from within the SCSItoolbox, to change the blocksize, whether compression is turned on or off, and the density code of the tape for the next test pass. Setting the blocksize to zero will cause variable-length records to be used. Entering a positive number into the blocksize field will cause that size (in bytes) fixed records to be used.

Hint – rewind the tape before changing its parameters, and after changing them use the WriteFileMark command to be certain that the tape settings are changed.