Device and channel 362

The NCAR Mbutt Storage System (MSS) is an archive server abused by being treated as a shared file system server. The mainframe (now an used early model z-8xx something, I can't ever remember the model number even though I walk past it several times a week) runs the PL-1 software that manages the operation of the system. The user submits a request to a local daemon, which contacts the management software on OS-390 (we've not quite gotten to z-OS yet). The management software mounts a tape if necessary, allocates data path resources and gives the location of the data on the device (disk-tape) to the daemon on the user's system, which then manages the transfer by directly building the CCW programs on the remote system and driving the storage device directly.

The system has migrated through three stages of the control and data fabrics (now popularly known as a SAN):

1) A HYPERChannel-based crossbar network. Used during the first years (1986-) for both the control connection and the data connection. The control connection was running home-grown software called, initially, the NCAR Local Network (NLN), but then morphed into being called the Mainframe and Server Network (MASnet).

2) A TCP LAN connection for the control connection with a switched HIPPI data fabric (mid-1990s-). We weaned ourselves off the HYPERChannel stuff out slowly. In stages, the MSS control traffic migrated off MASnet to TCP and the CCW programs were being sent via the HIPPI switched network to Network System's B-series adapters to block-mux or ESCON for disk or tape connectivity.

3) The TCP LAN connection for control remains, but the data trafic is being migrated to TCP over Gigabit Ethernet with software I wrote to replace the CCW program based parts of the system. The storage devices on the back end are either Fibre Channel RAID or tape attached to an SGI Origin 3900 running IRIX. The OS-390 software still manages the data placement, access and migration tasks, but every bit

The benefits of stage 3 is that we no longer have to worry about how to get hardware and drivers for the niche market HIPPI stuff, the software on the end-user's system is simplified because we no longer have to port and verify the CCW device driver part of the system, and we get much improved data rates to-from the newer storage devices with GigE-FC vs HIPPI-ESCON.

Occasionally we still run across data dependent hardware bugs in various systems and components. Lately we are averaging moving 4-6 TB per day, both in user requested transfers, and in the "data ooze" of migrating from older tape storage technologies to newer. However, that means it is no longer as impressive to take visitors on a tour of the machine room. Instead of pointing down long rows of 3490 cartridge racks holding 160,000+ tapes, we can only point to 5 STK Powderhorn silos with a mere 2+ PB of data and a few tens of TB of RAID in racks.