On Thu, Jun 12, 2003 at 05:50:17PM -0700, Jim Sibley wrote: > 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.
Well, since normal Unix tape handling has no concept of locking a drive to a single user (and certainly not against root), we're really trying to solve the "what system has a drive?" problem, I think. I was thinking more that in the scenario where the tapes are ATTACHed with the NOASSIGN parm, which is more like your case 2. I'd be more likely to define all the drives to all the Linux guests, allow the tape390 module to sense them and build device entries, and then use the 'mt reserve' approach to cause the virtual device entry to actually associate a real drive with that entry for however long the user needs it. The 'mt reserve' would trigger the driver to actually issue the attach/allocate CCWs for the real device, and issue a EBUSY if the drive isn't actually available. Your app could then act accordingly. Compare this to what happens when you try to umount a filesystem from under a running process. This approach would allow a guest to look at the list of devices (assuming we add a query function), and pick the one we want. We then acquire that drive, and do our stuff. When we're done, we "mt release" and it goes back to the unassigned pool. We don't end up constantly loading and unloading the device driver, the number and type of devices don't change at each turn, and we can limit what drives are available to a guest by what we define in the virtual machine (if we're smart, we could even do some dynamic stuff to signal CP to handle mounts). this approach would also be extensible to create a GRS-stile gadget without too much additional thought. Introducing this idea would also benefit the more general idea of at least writing an advisory lock when a user does a "mt reserve" on a non-z platform. > > 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. Which is fine, considering that a reserve/release could be implemented as an advisory lock on platforms w/o actual hardware reserver/release, and implemented as we need it on the Z. If it were run on a single system, it could be as simple as creating a lock file so that two processes don't try to write to the same device at the same time. You're right that mt works on the /dev structures. If you start from the assumption I mentioned above, then that's exactly where it should be. > 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? I'd argue to add an ioctl subfunction that mt (or other code) could use to trigger reservation of the device. 'mt' is the conduit for communicating that information for every other aspect of tape control, so I still think it's the right place for this function too. If done here, then adding a ioctl to the tape driver that handles reserve/release or mount processing, etc would be fairly straightforward.
