Scoring in Lacrosse is the glamour in the game, but what about the setup for a score?  That’s where the hard work is done.  The feeders and off-ball movement, whether it be a mid-fielder or an attack are what setup the plays.  Sometimes the feeders get an assist, sometimes not, but always the biggest part of a goal is the setup.  With all plays, there is a primary outlet and a secondary outlet. (See video.)

You can never predict how the defense will react, so you need a secondary outlet for scoring plays in case the primary outlet is covered and cannot get open.

Setting up a SAN (Storage Area Network) is no different.  It’s mandatory to have primary and secondary paths to your disk drives to protect against path failures.  This has been a defacto standard in SANs since the late 90’s, and has become a standard component in all of the premier OSs (Operating Systems) on the market today.  In the industry it’s called multi-pathing software, for OpenSolaris it’s a component called MPxIO.  Most storage companies have a significant investment here, too, as this signified a differentiator in the early days, but now most storage purchasers use what comes packaged in the OS.

So that’s great for disks, but what about tape devices?  Pretty significant storage component on the SAN, right?  In most cases - not an option.  Why?  It’s very difficult to do and requires coordination with tape applications, the OS and tape devices.

Tape devices are sequential; when things are going well (on writes) there are three basic things happening: 

• I/O is flowing without interruption to the tape device
• The I/Os are filling the buffer on the tape device and keeping the buffer full
• The actual tape is running at full speed with the buffer spilling onto it in the right location(s)

When things go badly, though, there’s a lot to be done:

• Validate that you have an alternate good path to the tape device
• Determine the last good write to the tape device and its proper location on tape
• Set up the I/O stream on the host to start after the last good write, making sure the order is preserved
• Reposition the tape to the correct point to restart the I/O stream
• Restart the I/O stream, loading the buffer again
• Start the tape movement and buffer spilling onto it

Today marks a banner day: build 93 of Open Solaris contains multi-pathing for tape.  Generic tape multi-pathing.  That’s right, the developers created a methodology that doesn’t require a special tape application, protocol or tape drives to provide the support.  Brilliant!!

So, how does it work?  Well, let’s go back to the lineage of development: 

• ST Logical Block Addressing – The first thing to do was to start using an absolute position instead of a relative one.  So inside the tape driver (ST – SCSI Tape),  instead of using file/block (count of files from the beginning of the tape partition and the block within a particular file – relative positioning) a conversion has been made to use logical block addressing (count of any entity recorded from the beginning of the tape partition – absolute positioning) all the time.  This was added in build 69 of OpenSolaris.
• ST Command Error Recovery – Dependent upon the SCSI command type for the tape device (Read, Write, etc.), the tape driver keeps track of the last command and expected position.  When an error occurs, the driver asks the tape device where it is on tape (The LBA – Logical Block Addressing).  Dependent upon the command type and position, the tape driver determines whether to resend the command or re-position and re-issue.  This was added in build 80 of OpenSolaris.
• Multi-pathing – Once the above was added, then tape devices could be added under the control of MPxIO in Solaris.  This means that upon an I/O error, the ST Command Error Recovery procedure is used, and if the error is path-related, an alternate path is used.  This was the last phase and just added in build 93 of OpenSolaris.

But wait, there’s more:

• The architecture of MPxIO is such that the driver is located below the tape driver (in the driver stack), and as a result, multiple paths to a tape device are not seen by tape applications.  For example, two paths to a single tape device in OpenSolaris will now show up as one tape device.  All re-routing and path management is handled behind the scenes.  This allows any tape application to use this feature.  No special handshake with the OS or tape driver required.
• By adding tape multi-pathing, it eliminates the reliance upon protocol error recovery.  The retries and recovery are protocol-independent, so you don’t need Fibre Channel FCP 2 error recovery or iSCSI ERL 1 or 2 in your protocol stack to add resiliency to your tape support.
• Supports all tape devices provided they support:

• MultiP bit or TPGS bit in Inquiry command and;
• SAN Connectivity and;
• Page 83 with type 1 support (binary WWN info) or;
• Special VID/PID in MPxIO (for legacy drives)

Wow, so what is next?  A whole new setup and set of plays with tape.  We’ve added single path asymmetrical multi-pathing support, but as we build out a portfolio on this, you can probably guess where we are headed next.  Tape support will be better in Solaris than any other OS on a SAN.  Any SAN - you pick the connectors, we’ll provide the rest.

Oh, and by the way, a little thing called “Tape Self-Identification” was added in build 78 of OpenSolaris.  This allows automatic pickup and configuration of tape drives without hand-editing .conf files or releasing patches with new tape drive additions.  A revolutionary way to support tape drives – the tape drive tells the OS how to configure it and what it is capable of.  All with standard SCSI commands.

Looks to me like the setup for tape got a great deal easier in OpenSolaris with a lot more options.  You can bet there will some high scores with this new set of plays.  Double hat-trick!