Good points. I was confusing attach and allocate. Given this, I think the discussion has gotten a bit confused about what problem we are trying to solve.
Even if we invent a way for a user to reserve a tape, I think the driver will still need to attach the tape at open() since a reserve may not have been done. Of course a reserve would have to attach the tape also, so the open() would have to check for that, and not try to attach again. Since open() would have to check for reserve anyway this should not be a problem. Just to be clear: the reserve of tapes would be a good general mechanism for Linux for all platforms. The attach would seem to be specific for z/series, but might also apply to systems running VMware and the like on Intel (although the hardware for Intel may not have any locking mechanism). -----Original Message----- From: Jim Sibley [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 5:50 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 I think we might be confusing several issues: 1) there are dedicated tapes to an OS host that can only be shared between the users on that hosts using software locks, 2) there are "shared tape" software mechanisms (tape managers) that allow different OS to share tapes using software locks, and 3) there are hardware locks that assign a tape to an OS. 1 - software locks: How the OS allows its users to share a tape (i.e., a software lock of some sort to allocate it to a user) once the tape is known to the hosts (JCL, tso allocate, JES3, current mt(?)). The tape must be assigned to the OS and only one user can use it at a time. This can be extended with a global resource manager (GRS) or a software tape manager that must be running on ALL hosts that can access the tapes. 2 - hardware locks: How different OS share a physcial drive through the zSeries 3480/3490/3590 hardware assign/unassign ccw's (which is like reserve/release on a disk volume). This is the mechanism for assigning a drive with the "shared tape feature" to the OS. The ccw assign command asks for the latch to be set on the hardware. If the device is available, not other host can ask for the drive until it is unassigned; if the device is assigned to another OS, then the ccw fails. This is at vary online or attach ... assign time. No special tape management software need be running. (the hardware latch is similar to the reserve/release on dasd - as long as a GRS type software manager is running on ALL hosts to communicate the software locks (enqueues), then they can be virtually eliminated. As long as one system is not running in the GRS ring, then reserve/release provides protection for the life of the reserve. In MVS, today, with GRS, about the only reserver still issued is for VTOC update on dasd - SYSVTOC enq). The shared tape notion I'm talking about is the hardware lock type as implemented on 3480/3490/3590 with the "shared" feature. Anyway, good point, John. Using insmod, you can't add a tape. You've have to delete the module and add any old tapes plus the new one as it is written today. One of the problems with the mt approach is that mt refers to the linux /dev/node structure, mapping the device addresses in order of occurrence to the /dev/*ibm* devices. And you would want to keep mt sufficiently generic to work with other platforms. However, exterior to Linux, things are handled by zSeries subchannel address and its insmod that associates the zSeries device address with the Linux /dev/node concept. So, what do you do? Modify tape390 module to handle the assign/unassign at insmod/delmod time for the duration of the time the tape is needed, or take ownership of mt to associate the device node with the zSeries subchannel address, or provide some other mechanism that passes to tape390 which tapes to assign and unassign? And I understand the devfs as implemented in zSeries may be going away with emphasis on UUID or VOLSER, neither of which apply to a zSeries tape. I liked the /dev/dasd/address approach or /dev/tape/address approach for zSeries (I was an early advocate of it in this forum), but I've stuck to using software table lookups of /proc tables to make the association between linux device node and zSeries device address since devfs is on its way out. I appreciate Boeblingen's effort to put it in, but it does not seem to be a long term solution. The basic problem is that 2400/.../3480/3490/3590 tapes and ESCON subchannels do not easily fit into the Linux notion of what devices ought to do. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens *** "Fargusson.Alan" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] tb.ca.gov> cc: Sent by: Linux on Subject: Re: Linux390 + VM + Tape 3490 390 Port <[EMAIL PROTECTED] IST.EDU> 06/12/2003 04:57 PM Please respond to Linux on 390 Port In batch it happens at the allocate, which I think is at start of job in JES3, and start of step in JES2. In TSO you do an allocate command, although I doubt many people do this. Usually they write some JCL, and submit it. I think an allocate command would be the best way to do this in Linux, since it would be about the same as TSO. I think that the mt command is not the right place to do this though. -----Original Message----- From: John Summerfield [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:35 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 On Thu, 12 Jun 2003, Jim Sibley wrote: > John, > > "insmod tape390 tape=xxx,xxx" - only list the tapes you want to use are > specified. Obviously, putting them in the zipl.conf would lock them for the > duration of the IPL - not good for shared tapes. Having loaded tape390 once, can you then load it again to get another tape? Having the mt command handle locking/releasing looks good to me, coupled with the driver spitting the dummy if you try to do anything to an unreserved tape except reserve it, or detach it. "mt attach" sounds good to me too. On systems where attach/detach don't apply, the operations should give no error or warning. I can imagine this functionality applying in other environments (such as vmware), and it seems to me ideal for the semantics to be the same. > However you look at it, the solution requires the person using the machine > to take overt acton to obtain the drive and it must be locked until he is > ready to release it. And it needs to take into account the fact that other > OS (non-linux) may also use the same drive. I'm not keen on the idea of it being done at driver-load time. > In this case, I think it behooves Linux to comply with the rules already in > place for shared tapes in an installation and follow the rules for the > device as defined in the hardware specs. When does it happen in OS/390? -- Cheers John. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
