> > I'd really like to see iSCSI succeed -- it'd make a very elegant > > solution to some of the device sharing problems we see in > mixed z/OS > > and z/VM > shops > > wrt tape drives. > > David, would you mind to elaborate? Do you suggest to use an > iSCSI tape device attached to Linux to do backup of z/VM or z/OS data? > As far as I know, z/OS doesn't support SCSI at all.
OK (acknowledgement in public required if you turn this into a product...): I see two major roles for iSCSI for mainframe Linux: to handle the case where we need to present non-SCSI devices (like channel attached tape) to Linux in a standardized way, and to avoid having to make Linux aware of how to assign/unassign devices between LPARs. It happens to enable some other useful stuff, but these two items are IMHO the biggest gains in the short term. In the first case, given that iSCSI provides a well-defined protocol interface for presenting a "device" in a Linux system or guest accessing a remote device over IP, iSCSI would allow a standardized method to present devices owned by other operating systems to a Linux system regardless of the actual method of accesing the remote device. Linux would no longer always need specific drivers for specific hardware types; a generic SCSI I/O driver would suffice in most cases. For example, it would be relatively simple to implement a iSCSI started task on z/OS or virtual machine on z/VM (for example) that allocated channel attached tape drives on z/OS and presented them to Linux as emulated SCSI tape drives. If the iSCSI implementation was well done, the standard SCSI tape changer interface commands could be implemented as a SCSI device and mapped to the proprietary interfaces for operating channel-attached tape libraries within the iSCSI server (or to a z/OS or z/VM TMS, if present), eliminating the need to publish the tape library channel interfaces, but allowing internal *and* external systems to access expensive mainframe devices in a standardized way and allowing non-Z systems to benefit from the superior mainframe storage management capabilities and discipline. Second, by using IP and leveraging the high-speed transport present within hipersocket connections, the need for Linux to be aware of mainframe assign/unassign protocols and handling dynamic attach/detach of devices essentially vanishes. Configuring an iSCSI device is handled completely within the hotplug framework already present in Linux. The fat pipe provided by a hipersocket is easily sufficient to support acceptable rates of data transfer between a device owned by z/OS or z/VM and a client system on a internal guest, and IP is suitable for just about any external platform to become a client -- it becomes a question of network engineering, not device driver creation. iSCSI is generic enough to handle a number of different devices using a common transport. (IMHO, if there is a semi-easy way to eliminate one more "different/weird" thing about mainframe Linux, then I'm for it. It also happens to work for iSCSI disk, and pretty much anything you can cobble together a "SCSI-like" mapping for an existing device.) The drive towards SCSI-only support in Linux that IBM has pursued would be much more understandable if something like this approach was present -- if we could use our existing equipment via a mediation layer like iSCSI, then we get the best of both worlds, and you get the benefit of using existing assets more effectively, improving the TCO of the Linux and mainframe combination. Does that help? -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
