Re: Linux390 + VM + Tape 3490
I can't think of any problems with using sysctl(). -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 3:37 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 On Fri, 13 Jun 2003, Fargusson.Alan wrote: Actually you hit on the problem with using mt. Before you can do an ioctl() you have to open() the tape, but before you can open() the tape you have to allocate it. I don't see how you can use ioctl() to allocate the tape. Any objection to sysctl()? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
sysctl sounds like a good approach. It gets around the problem I mentioned above correlating the OS device address with the device node. And it only has to be used on tape drives that require the assign/unassign. Whatever mechanism is used, it must prevent real I/O (read/write/rewind/woef) to the device unless the latch is set properly. The protocol would have to be something like: 1 - make the tape devices known to the host (insmod/modprobe/zipl.conf) with devices unassigned 2 - sysctl assign a drive a - if sysctl assign succeeds, allow I/O to the drive b - if sysctl assign fails or has not been set, ALL I/O fails to the drive 3 - sysctl unassign drive when user is finished with drive Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
I've watched threads here on how idle Linux guests chew on CPU because Linux PC versions expect the whole system to be idle if they are idle. That's because we push the limits. We get upset because an idle Linux uses 0.01% of a CPU, but for many installations this is not a show-stopper. I've watched threads here about paging conflicts between VM trying to page and Linux trying to page. That's an issue for any operating system that provides virtual memory when you run it in a virtual machine. I believe the same applies to VSE dynamic partitions. It is a trade-off that must be made based on workload and available resources. I believe there is a vague boundary between being different and being the same. Linux on z/VM is both different from Linux on other platforms, and it must be the same as on other platforms. If there were only arguments in favor of one single solution, life would be easy. Rob
Re: Linux390 + VM + Tape 3490
Like VSE, when you IPL native, the VM interfaces are turned off and VSE manages the resources. If we are going to treat Linux like a real operating system, like MVS VSE, it should be able to perform like a real operating system. It may not be a popular opinion, but Linux/390 is NOT a personal computer operating system and should be provided the interfaces it needs to properly exploit the environment in which it is running, which are the interfaces for media, memory and CPU management. I've watched threads here on how idle Linux guests chew on CPU because Linux PC versions expect the whole system to be idle if they are idle. I've watched threads here about paging conflicts between VM trying to page and Linux trying to page. VSE internal behavior is different when it is IPL'd as a guest of VM and when it is IPL'd native, in paging and I/O. So does MVS, Linux should use them as a model and co operate with VM to best exploit the environment. Garry E. Ward Senior Software Specialist Maritz Research, Automotive Research Group 419-725-4123 -Original Message- From: Jim Sibley [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 5:20 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 So what happens when Linux is running in an LPAR or native? Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens *** Ward, Garry [EMAIL PROTECTED]To: [EMAIL PROTECTED] z.com cc: Sent by: Linux onSubject: Re: Linux390 + VM + Tape 3490 390 Port [EMAIL PROTECTED] IST.EDU 06/13/2003 09:21 AM Please respond to Linux on 390 Port That is what I've been thinking. VSE/EPIC has an auto attach feature. Basically boils down to any given guest wants a tape drive, it should politely ask VM for it, accept whatever it is given with a thank you and give it back nicely when done. Guests are guests, they should co operate with the host. Garry E. Ward Senior Software Specialist Maritz Research, Automotive Research Group 419-725-4123 -Original Message- From: Tom Duerbusch [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 11:41 AM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 Parden the interruption. I would like to get some clairification about just who is affected. I've been following these posts... When I use tape directly from Linux (Suse), I attach/detach the tape drives. (Of course, running under z/VM) I don't seem to have any of the problems being discusses. I do recall something about z/OS and LPARs being able to dynamically use tape drives and, perhaps, this is the kind of use that this type of problem surfaces with. So, does this problem affect VM types that attach/detach? Perhaps I've been kidding my self that my Linux tape usage hasn't been causing problems. Perhaps Dynam/T has been correcting these problems. Perhaps Operations been correcting these problems and not telling me (yearight..that will be the day). Tom Duerbusch THD Consulting Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: Linux390 + VM + Tape 3490
On Thursday, 06/12/2003 at 05:50 MST, Jim Sibley/San Jose/[EMAIL PROTECTED] wrote: I think we might be confusing several issues I think everyone has a good understanding of the issues, Jim. A requirment to unload/reload the device driver is a non-starter and voids all of the dynamic device support. To add a tape you must take all other tapes out of service. That isn't a good strategy. Do you agree with that? The point with shared tapes, whether it is a logical or physical sharing, is that there is *something* under program and/or user control to say This is mine until I say it is not. That function is the thing that must issue the assign/unassign. (I beg everyone not to call it attach or detach... those words imply a change in the host device configuration...assign/unassign do not change the configuration.) I think that Mr. Boyes is on the right track. This is a function that any platform that wants to maintain a static device configuration, but allow a device to go into away state will want. There is no need for a special mainframe-specific paradigm that is somehow imbedded in the driver. As David said, define a new reserve/release ioctl() that will do this and let the apps (e.g. mt) deal with it. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
This sounds a lot like the kind of processing that hotplug should do? David Alan Altmark [EMAIL PROTECTED]To: [EMAIL PROTECTED] s.ibm.com cc: Sent by: Linux Subject: Re: Linux390 + VM + Tape 3490 on 390 Port [EMAIL PROTECTED] ARIST.EDU 13/06/2003 14:38 Please respond to Linux on 390 Port On Thursday, 06/12/2003 at 05:50 MST, Jim Sibley/San Jose/[EMAIL PROTECTED] wrote: I think we might be confusing several issues I think everyone has a good understanding of the issues, Jim. A requirment to unload/reload the device driver is a non-starter and voids all of the dynamic device support. To add a tape you must take all other tapes out of service. That isn't a good strategy. Do you agree with that? The point with shared tapes, whether it is a logical or physical sharing, is that there is *something* under program and/or user control to say This is mine until I say it is not. That function is the thing that must issue the assign/unassign. (I beg everyone not to call it attach or detach... those words imply a change in the host device configuration...assign/unassign do not change the configuration.) I think that Mr. Boyes is on the right track. This is a function that any platform that wants to maintain a static device configuration, but allow a device to go into away state will want. There is no need for a special mainframe-specific paradigm that is somehow imbedded in the driver. As David said, define a new reserve/release ioctl() that will do this and let the apps (e.g. mt) deal with it. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
On Friday, 06/13/2003 at 02:28 CET, David Goodenough [EMAIL PROTECTED] wrote: This sounds a lot like the kind of processing that hotplug should do? David In 2.5/2.6, things will change because of the generalized Linux support for dynamic I/O config changes, with automatic execution of device startup/cleanup scripts, etc. (If that's what you mean by hotplug not sure what the official Linux name for this function is.) But I think you do not want automatic assignment of a drive that comes online (attached, in VM terms). That needs to wait until the drive is actually needed. The point is that assignment of a drive when it comes online or at driver load time prevents any kind of multi-host sharing. It's not a Linux problem, per se, but a driver issue. The real point of discussion is whether the mt, UTS or a combination approach is best. One of the advantages I see in the UTS approach is that the driver can prevent access to the standard label, just as the dasd drivers do for disks. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
On Fri, 13 Jun 2003, David Goodenough wrote: This sounds a lot like the kind of processing that hotplug should do? Not exactly, IMO. Hotplug responds to plugging something in, and to pulling it out. Equivalent of a VM attach/detach. What we want is to have the tape drives attached pretty-much all the time to lots of machines, Someone wanting a tape drive runs a command, maybe mt, to say so. They do not use VM's attach - indeed, they may not have a VM account with which to do so. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
Hotplug is a separate package that hooks into the kernel through a kernel module and does all this dynamic config change stuff. It works quite happily in 2.4, and is developed on into 2.5/2.6. It was written really for USB and then worked in with the PCMCIA and PCI hotplug stuff. It does require some hooks in the device drivers. It does not assign to users, it does give sensible names to devices. There was also recently a patch to further help partition devices which might he helpful here. Thus if you plug in a USB Zip drive, it will make sure that the usb-storage module is loaded which will allocate is a /dev/sd? number. The patch goes a bit further and creates a logical device (/dev/zipx) which can then be the subject of a mount request. The reason for needing this is that if you have a camera and a zip drive, which /dev/sd? you get depends on which order you plug them in, and this makes fstab entries difficult to use. With the patch it gets easier because you do not normally have more than one camera or zip drive in a PC. Now on a mainframe this is more difficult, and a slightly different approach may be required, but the principle holds. You might for instance have the device named by its label, so /dev/dasd/label rather than /dev/dasd? where ? is a number. I think the framework is flexible enough to do this. David Alan Altmark [EMAIL PROTECTED]To: [EMAIL PROTECTED] s.ibm.com cc: Sent by: Linux Subject: Re: Linux390 + VM + Tape 3490 on 390 Port [EMAIL PROTECTED] ARIST.EDU 13/06/2003 15:00 Please respond to Linux on 390 Port On Friday, 06/13/2003 at 02:28 CET, David Goodenough [EMAIL PROTECTED] wrote: This sounds a lot like the kind of processing that hotplug should do? David In 2.5/2.6, things will change because of the generalized Linux support for dynamic I/O config changes, with automatic execution of device startup/cleanup scripts, etc. (If that's what you mean by hotplug not sure what the official Linux name for this function is.) But I think you do not want automatic assignment of a drive that comes online (attached, in VM terms). That needs to wait until the drive is actually needed. The point is that assignment of a drive when it comes online or at driver load time prevents any kind of multi-host sharing. It's not a Linux problem, per se, but a driver issue. The real point of discussion is whether the mt, UTS or a combination approach is best. One of the advantages I see in the UTS approach is that the driver can prevent access to the standard label, just as the dasd drivers do for disks. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
On Friday, 06/13/2003 at 03:35 CET, David Goodenough [EMAIL PROTECTED] wrote: Now on a mainframe this is more difficult, and a slightly different approach may be required, but the principle holds. You might for instance have the device named by its label, so /dev/dasd/label rather than /dev/dasd? where ? is a number. I think the framework is flexible enough to do this. I think 2.5/2.6 will show it based on device address. Can't use label because labels aren't unique. Device addresses are. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
MTBF of decades, provided nothing extra-boneheaded happens, like short out your main power panel in the basement. Oh, the fireworks that happened up here on THAT day several years ago. |-+ | | John Summerfield | | | [EMAIL PROTECTED]| | | afe.com.au | | | Sent by: Linux on 390| | | Port | | | [EMAIL PROTECTED]| | | EDU | | || | || | | 06/12/2003 06:11 PM | | | Please respond to| | | Linux on 390 Port| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Linux390 + VM + Tape 3490 | --| On Thu, 12 Jun 2003, Richard Hitt wrote: Hi, Jim Since Paul's on South African time and I'm here in California, I had a go. The UTS Global Tape Subsystem includes the command tapevary(8), used mainly to vary online a tape drive to the system. So, tapevary on 3028 varies drive 3028 online. It causes the UTSG tape driver to perform an attach, and tapevary off 3028 performs an unattach. If I have 3028 varied online to one VM Linux and try to vary it online at another, the Drive Assigned Elsewhere message appears. So consider it verified, at least under VM. We had a power outrage, um, outage, today and besides I see no recognition in our driver's code that Hmm. Seems to me that zBoxes are dropping like flies;-) I was at an IBM presentation the other day, where they were talking about MTBF of decades. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
Parden the interruption. I would like to get some clairification about just who is affected. I've been following these posts... When I use tape directly from Linux (Suse), I attach/detach the tape drives. (Of course, running under z/VM) I don't seem to have any of the problems being discusses. I do recall something about z/OS and LPARs being able to dynamically use tape drives and, perhaps, this is the kind of use that this type of problem surfaces with. So, does this problem affect VM types that attach/detach? Perhaps I've been kidding my self that my Linux tape usage hasn't been causing problems. Perhaps Dynam/T has been correcting these problems. Perhaps Operations been correcting these problems and not telling me (yearight..that will be the day). Tom Duerbusch THD Consulting
Re: Linux390 + VM + Tape 3490
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 onSubject: Re: Linux390 + VM + Tape 3490 390 Port [EMAIL PROTECTED
Re: Linux390 + VM + Tape 3490
If you're running under VM, and have VMTAPE in use, and have Neale's cpint package installed and working, it seems to me you should be able to do something like hcp sm vmtape mount volser 181 and have VMTAPE (with STAM if your tape drives are EMIF'ed among multiple LPARs) mount the tape, then insmod tape390 tape=181 and do something with /proc to make the 181 tape device active. At this point, you should be able to work with the tape itself using tar or mt. to release the tape, you'd have to delmod tape390 hcp detach 181. I can only see two problems with this approach: (1) I think tape390 and cpint use the same major node numbers. You might have to recompile one or the other to use a different major node number. (2) I've never been able to get cpint to properly issue a CP DETACH command that works. I may be doing something wrong. Anyone care to comment on this approach? Great Minds discuss ideas. Average minds discuss events. Small minds discuss people. - Admiral Hyman Rickover Gordon Wolfe, Ph.D. (425)856-5940 VM Enterprise Servers, The Boeing Company -- From: Fargusson.Alan Reply To: Linux on 390 Port Sent: Thursday, June 12, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 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
Re: Linux390 + VM + Tape 3490
Actually you hit on the problem with using mt. Before you can do an ioctl() you have to open() the tape, but before you can open() the tape you have to allocate it. I don't see how you can use ioctl() to allocate the tape. Perhaps I know too much about how drivers work to see this the way the user would like this to work. -Original Message- From: David Boyes [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 5:40 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 On Thu, Jun 12, 2003 at 05:31:39PM -0700, Fargusson.Alan wrote: The mt command is designed to control a tape drive. An allocate command would be used to gain access to a tape drive, and prevent others from using it. Perhaps this seems like a fine point, but I prefer to separate the functionality. I guess I'm puzzled about what the distinction is. Allocation (IMHO) seems to be a tape control function -- it's clearly discrete from reading and writing the data on the tape, and 'mt' contains every other function that is not directly related to reading and writing the tape. All mt does is execute ioctl's to control tape function, just like the TSO ALLOCATE command performs the standard allocation functions driven by a chunk of command line code. How is this any different?
Re: Linux390 + VM + Tape 3490
On Friday, 06/13/2003 at 08:57 MST, Wolfe, Gordon W [EMAIL PROTECTED] wrote: If you're running under VM, and have VMTAPE in use, and have Neale's cpint package installed and working, it seems to me you should be able to do something like hcp sm vmtape mount volser 181 and have VMTAPE (with STAM if your tape drives are EMIF'ed among multiple LPARs) mount the tape, then insmod tape390 tape=181 and do something with /proc to make the 181 tape device active. At this point, you should be able to work with the tape itself using tar or mt. to release the tape, you'd have to delmod tape390 hcp detach 181. I can only see two problems with this approach: (1) I think tape390 and cpint use the same major node numbers. You might have to recompile one or the other to use a different major node number. (2) I've never been able to get cpint to properly issue a CP DETACH command that works. I may be doing something wrong. Anyone care to comment on this approach? What if you have two drives attached? Process 1 is writing to 181, process 2 is writing to 182. Process 2 ends and you are finished with 182. Process 1 is still running (syslog is piped to it - it isn't gonna end any time soon). How do you release the drive? Yes, you could DETACH it. But what if this is an LPAR? Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
Actually you hit on the problem with using mt. Before you can do an ioctl() you have to open() the tape, but before you can open() the tape you have to allocate it. I don't see how you can use ioctl() to allocate the tape. Take a peek at blockdev. It does a similar sort of thing to what I was thinking about. Perhaps I know too much about how drivers work to see this the way the user would like this to work. Here's how I'd envision it working: At IPL, the Linux guest is informed that it's allowed to use tape addresses 10-20 in the zipl setup. The tape390 driver loads at boot, assumes that the tapes are in shared mode (or is told to do so via a parm), builds device entries for those drives, but does not issue ASSIGN CCWs at that time. The drives stay unallocated until someone wants to use one. User issues mt reserve /dev/mt0 (or whatever device he wants to use). mt signals the device driver that a user has issued the reserve via ioctl(). Driver wakes up, issues the ASSIGN CCW. If successful (meaning the drive is now ours), we return rc=0 to the user and he can start doing his thing. If the assign fails, we issue an error to the user and it's up to him to cope. User reads and writes to his heart's content. User is done with tape and issues mt release /dev/mt0. mt signals device driver that user released device via ioctl(). Driver wakes up, issues the release CCW. Physical drive goes back into the pool, device entry remains live Another idea I had was that perhaps the solution is for the tape390 driver to produce a psuedodevice (say /dev/mtctl0) for each real tape device that would allow issuing various commands to a underlying control layer (kind of like the extra device that the SCSI tape libraries use for manipulating the changer). If we set up the assumption that every drive is a library (single drives are treated as a one-drive changer), the model would work with mt, or with the UTS model, but at the expense of burning more device entries/minor #s. It'd also provide a way to trigger mounts, etc if needed. I don't like this solution very much in that it complicates the model, but it might satisfy some of the objections presented so far. It would also work with the existing Intel stuff (might even make that more general). I guess I don't see why this is so different from some of the special functions that mt already has for dealing with SCSI tapes. It's really not all that different semantically than setting the recording density or compression options before you start writing to a tape. Wrt to the unloading/reloading the tape driver, I don't think that losing all the tapes just to change the options on one drive is really an acceptable solution. There needs to be some way to work with individual drives.
Re: Linux390 + VM + Tape 3490
This would reserve the tape to that machine, but would allow another user on the same machine to use the tape. Maybe that is what you want, but that is not what reserve implies. Figuring out how to prevent other users from using the tape is a tricky problem. I am not sure what that would even mean. Would you reserve by UID, or by process control group, or something else? -Original Message- From: David Boyes [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 9:38 AM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 Actually you hit on the problem with using mt. Before you can do an ioctl() you have to open() the tape, but before you can open() the tape you have to allocate it. I don't see how you can use ioctl() to allocate the tape. Take a peek at blockdev. It does a similar sort of thing to what I was thinking about. Perhaps I know too much about how drivers work to see this the way the user would like this to work. Here's how I'd envision it working: At IPL, the Linux guest is informed that it's allowed to use tape addresses 10-20 in the zipl setup. The tape390 driver loads at boot, assumes that the tapes are in shared mode (or is told to do so via a parm), builds device entries for those drives, but does not issue ASSIGN CCWs at that time. The drives stay unallocated until someone wants to use one. User issues mt reserve /dev/mt0 (or whatever device he wants to use). mt signals the device driver that a user has issued the reserve via ioctl(). Driver wakes up, issues the ASSIGN CCW. If successful (meaning the drive is now ours), we return rc=0 to the user and he can start doing his thing. If the assign fails, we issue an error to the user and it's up to him to cope. User reads and writes to his heart's content. User is done with tape and issues mt release /dev/mt0. mt signals device driver that user released device via ioctl(). Driver wakes up, issues the release CCW. Physical drive goes back into the pool, device entry remains live Another idea I had was that perhaps the solution is for the tape390 driver to produce a psuedodevice (say /dev/mtctl0) for each real tape device that would allow issuing various commands to a underlying control layer (kind of like the extra device that the SCSI tape libraries use for manipulating the changer). If we set up the assumption that every drive is a library (single drives are treated as a one-drive changer), the model would work with mt, or with the UTS model, but at the expense of burning more device entries/minor #s. It'd also provide a way to trigger mounts, etc if needed. I don't like this solution very much in that it complicates the model, but it might satisfy some of the objections presented so far. It would also work with the existing Intel stuff (might even make that more general). I guess I don't see why this is so different from some of the special functions that mt already has for dealing with SCSI tapes. It's really not all that different semantically than setting the recording density or compression options before you start writing to a tape. Wrt to the unloading/reloading the tape driver, I don't think that losing all the tapes just to change the options on one drive is really an acceptable solution. There needs to be some way to work with individual drives.
Re: Linux390 + VM + Tape 3490
Alan wrote: I think everyone has a good understanding of the issues, Jim. Based on the previous and subsequent posts to this thread after this statement , based on Boeblingen's design of the tape390 driver, and based on the restrictions on the Developer works pages for the tape staring, I think you assume too much about who understands what or we wouldn't be having this discussion. ;) And those that only approach the problem from the a single OS point of view (Linux or VM/Linux) are missing the point that the shared ESCON tape drives can be used by multiple OS on multiple LPAR's on multiple CEC's. Or that the operations staff that have to operate these tape drives may be many kilometers away for both the CEC's and the users. Doing a search of the literature from IBM, you might find out that DB2 UDB is not certified for shared tapes in the backup command because of these restrictions (probably in some very obscure footnote somewhere). Why? issue backup to tape on a linux LPAR or EC guest issue vary online on in an MVS LPAR or attach on for and EC guest on any LPAR on any CEC that shares the drive SLES7 - at any time, the backup copy is as good as toast and the data is available to the other hosts. SLES8 - after the backup, the backup copy is as good as toast and the data is available to other hosts. That does not sound to me as if there is a good understanding of how the mechanism works! As long as you use attach under VM (with the default of assign), you can operate fat dumb and happy. As soon as you specify unassign or you try to run in LPAR mode, you run into both data integrity and data security problems big time. If everyone had a good understanding of how ESCON shared tape worked, then it would have been implemented differently in the first place. Linux zSeries is still on the low end of the learning curve on this issue. To answer Tom's question about the extent of the problem: 1 - If you have tape dedicated to the LPAR and no other LPAR can access the tape you do not have the problem. 2 - running under VM, using attach with the default of assigned, you have do not have the problem. 3 - running under VM, using attach with unassign, you are exposed to the problem (the issue that started this thread). 4 - if you are running native or in an LPAR, w/o VM, you are exposed to the problem. If you are exposed to the problem, you can have data integrity and data security problems caused by other EC guests, other LPARS, other CECs, and other OS who have a path to these tapes. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
Great...Thanks Jim Tom Duerbusch THD Consulting What me worry? To answer Tom's question about the extent of the problem: 2 - running under VM, using attach with the default of assigned, you have do not have the problem.
Re: Linux390 + VM + Tape 3490
That is what I've been thinking. VSE/EPIC has an auto attach feature. Basically boils down to any given guest wants a tape drive, it should politely ask VM for it, accept whatever it is given with a thank you and give it back nicely when done. Guests are guests, they should co operate with the host. Garry E. Ward Senior Software Specialist Maritz Research, Automotive Research Group 419-725-4123 -Original Message- From: Tom Duerbusch [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 11:41 AM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 Parden the interruption. I would like to get some clairification about just who is affected. I've been following these posts... When I use tape directly from Linux (Suse), I attach/detach the tape drives. (Of course, running under z/VM) I don't seem to have any of the problems being discusses. I do recall something about z/OS and LPARs being able to dynamically use tape drives and, perhaps, this is the kind of use that this type of problem surfaces with. So, does this problem affect VM types that attach/detach? Perhaps I've been kidding my self that my Linux tape usage hasn't been causing problems. Perhaps Dynam/T has been correcting these problems. Perhaps Operations been correcting these problems and not telling me (yearight..that will be the day). Tom Duerbusch THD Consulting Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: Linux390 + VM + Tape 3490
So what happens when Linux is running in an LPAR or native? Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens *** Ward, Garry [EMAIL PROTECTED]To: [EMAIL PROTECTED] z.com cc: Sent by: Linux onSubject: Re: Linux390 + VM + Tape 3490 390 Port [EMAIL PROTECTED] IST.EDU 06/13/2003 09:21 AM Please respond to Linux on 390 Port That is what I've been thinking. VSE/EPIC has an auto attach feature. Basically boils down to any given guest wants a tape drive, it should politely ask VM for it, accept whatever it is given with a thank you and give it back nicely when done. Guests are guests, they should co operate with the host. Garry E. Ward Senior Software Specialist Maritz Research, Automotive Research Group 419-725-4123 -Original Message- From: Tom Duerbusch [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 11:41 AM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 Parden the interruption. I would like to get some clairification about just who is affected. I've been following these posts... When I use tape directly from Linux (Suse), I attach/detach the tape drives. (Of course, running under z/VM) I don't seem to have any of the problems being discusses. I do recall something about z/OS and LPARs being able to dynamically use tape drives and, perhaps, this is the kind of use that this type of problem surfaces with. So, does this problem affect VM types that attach/detach? Perhaps I've been kidding my self that my Linux tape usage hasn't been causing problems. Perhaps Dynam/T has been correcting these problems. Perhaps Operations been correcting these problems and not telling me (yearight..that will be the day). Tom Duerbusch THD Consulting Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: Linux390 + VM + Tape 3490
On Fri, 13 Jun 2003, Fargusson.Alan wrote: 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. I did suggest that trying to open an unreserved tape should result in an error. 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). Whether the hardware has it or not, the emulator (vmware) can implement a locking mechanism. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
On Fri, 13 Jun 2003, Wolfe, Gordon W wrote: If you're running under VM, and have VMTAPE in use, and have Neale's cpint package installed and working, it seems to me you should be able to do something like hcp sm vmtape mount volser 181 and have VMTAPE (with STAM if your tape drives are EMIF'ed among multiple LPARs) mount the tape, then insmod tape390 tape=181 and do something with /proc to make the 181 tape device active. At this point, you should be able to work with the tape itself using tar or mt. to release the tape, you'd have to delmod tape390 hcp detach 181. I can only see two problems with this approach: (1) I think tape390 and cpint use the same major node numbers. You might have to recompile one or the other to use a different major node number. (2) I've never been able to get cpint to properly issue a CP DETACH command that works. I may be doing something wrong. Anyone care to comment on this approach? And it you subsequently want another tape drive? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
On Fri, 13 Jun 2003, Fargusson.Alan wrote: Actually you hit on the problem with using mt. Before you can do an ioctl() you have to open() the tape, but before you can open() the tape you have to allocate it. I don't see how you can use ioctl() to allocate the tape. Any objection to sysctl()? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
On Fri, 13 Jun 2003, Fargusson.Alan wrote: This would reserve the tape to that machine, but would allow another user on the same machine to use the tape. Maybe that is what you want, but that is not what reserve implies. Figuring out how to prevent other users from using the tape is a tricky problem. I am not sure what that would even mean. Would you reserve by UID, or by process control group, or something else? That is altogether a different problem, and one that needs to be addressed for all platforms. Think tapes, CD/DVD, scanners. Linux is multiuser, and it makes good sense to run it that way: my wife and I both login to the Athlon at home from lesser machines. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
Alan Altmark wrote : Perhaps the UTS drivers are better behaved? File open-to-close doesn't sound like a very useful paradigm (but I don't know how Linux applications use tape drives) and I don't know if one part of Linux can open a tape file (tape management system, just to lock the drive and to request a tape mount) and another part of Linux subsequently opening-writing/reading-closing the same tape so that the drive is not unassigned until the tape management system closes the tape file. Minimally the UTSG Tape Management System will lock the drive(s) and manage tape mount requests, once tapes are mounted the UTSG driver makes the mounted tape accessible to user/app via a logical device named after the tape volume name. eg: /dev/tape/AB0020 The UTSG Distributed Tape Subsystem extends this paradigm to systems remote from the Linux/390 tape server(s). Paul.
Re: Linux390 + VM + Tape 3490
File open-to-close doesn't sound like a very useful paradigm (but I don't know how Linux applications use tape drives) and I don't know if one part of Linux can open a tape file (tape management system, just to lock the drive and to request a tape mount) and another part of Linux subsequently opening-writing/reading-closing the same tape so that the drive is not unassigned until the tape management system closes the tape file. The implementation is what you would expect for a shared printer, a write only device - during write, the device is dedicated and after the write, the data is no longer available. The assign is done at open/close time, I suspect if one applicaiton assigns the drive and leaves it assigned, then another application uses the drive, then the the assign would be dropped after the second app closes the file. As implemented, is dangerous for shared tape, as it does not allow time for operator intervention (loading/unloading the tape) before it is used by another hosts, and 2) two hosts could rewind and/or record to the same tape without knowing it. For example, tar is an applicaiton that can write to the tape directly and read it back. tar -cvpi -f /dev/ntibm0 some time later (during this time, another system could do a similar function) tar -xzpi -f /dev/ntibm0 results could be unpredictable or you might get someone elses data! I think I'll crank up two hosts on our VM system and see what really happens under VM. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
Paul, have you physically verified that UTSG actually works this way on s/390 in both LPAR or under VM? Does it apply to ECKD shared tapes, not dedicated tapes? It the lock a UTSG lock or is it a hardware assign/unassign. Without the hardware assign/unassign, it is not really locked from other hosts in the s/390 environment. Minimally the UTSG Tape Management System will lock the drive(s) and manage tape mount requests, once tapes are mounted the UTSG driver makes the mounted tape accessible to user/app via a logical device named after the tape volume name. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
Jim, What is an ECKD shared tape? I thought ECKD was Extended Count Key Data and only applied to DASD. Is this another reused acronym? -- John McKown Senior Systems Programmer UICI Insurance Center Applications Solutions Team +1.817.255.3225 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: Jim Sibley [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 12:05 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 Paul, have you physically verified that UTSG actually works this way on s/390 in both LPAR or under VM? Does it apply to ECKD shared tapes, not dedicated tapes? It the lock a UTSG lock or is it a hardware snip
Re: Linux390 + VM + Tape 3490
I'm sorry - you're right - there is no such thing as ECKD tape. Wrong term - I hope you can write that off as a senior moment ;) What I meant was ESCON subchannel tapes. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
The assign is done at open/close time, I suspect if one applicaiton assigns the drive and leaves it assigned, then another application uses the drive, then the the assign would be dropped after the second app closes the file. Methinks the Right Thing To Do would be to add function to mt to allow it to reserve a drive (eg, mt reserve /dev/st0) when a application wants on, and provide a release function when you're done with it (eg mt release /dev/st0). That would be generic enough to handle most of the Intel cases as well, but would suit us nicely(*). -- db * - setting an advisory lock or using flock/lockf() to create a lock file that other applications could query if need be.
Re: Linux390 + VM + Tape 3490
Dave wrote: Methinks the Right Thing To Do would be to add function to mt to allow it to reserve a drive (eg, mt reserve /dev/st0) when a application wants on, and provide a release function when you're done with it (eg mt release /dev/st0). That would be generic enough to handle most of the Intel cases as well, but would suit us nicely(*). Since its really a zSeries notion, it seems to me putting the assign/unassign in insmod/delmod tape390 initialization somehow would be more appropriate. Also, the way the tapes have been implemented (by dev node), there is no mount involved. Mounts in linux don't really mount devices - they mount file systems. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
Has anyone succesfully made Linux on 390 talk to a 3494 and place nice with the resources or does it have to own a drive. |-+ | | Jim Sibley | | | [EMAIL PROTECTED]| | | com | | | Sent by: Linux on| | | 390 Port | | | [EMAIL PROTECTED]| | | IST.EDU | | || | || | | 06/12/2003 02:25 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Linux390 + VM + Tape 3490 | --| Dave wrote: Methinks the Right Thing To Do would be to add function to mt to allow it to reserve a drive (eg, mt reserve /dev/st0) when a application wants on, and provide a release function when you're done with it (eg mt release /dev/st0). That would be generic enough to handle most of the Intel cases as well, but would suit us nicely(*). Since its really a zSeries notion, it seems to me putting the assign/unassign in insmod/delmod tape390 initialization somehow would be more appropriate. Also, the way the tapes have been implemented (by dev node), there is no mount involved. Mounts in linux don't really mount devices - they mount file systems. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
Since its really a zSeries notion, it seems to me putting the assign/unassign in insmod/delmod tape390 initialization somehow would be more appropriate. Also, the way the tapes have been implemented (by dev node), there is no mount involved. Mounts in linux don't really mount devices - they mount file systems. mt is the generic tape manipulation utility -- no implication of mount at all. All the other generic utility tape handling function (eg fsf, rewind, etc) are in mt, so thus the suggestion for putting the function into mt. Unloading and loading the device driver to effect reservation seems broken to me (yes, it's how it's implemented right now, but it still seems wrong) as it's not that the device is appearing/disappearing (the device remains attached), but whether a system has a reservation on using the device. That's certainly not 390-specific -- I've been wanting this kind of semantics forever.
Re: Linux390 + VM + Tape 3490
Hi, Jim Since Paul's on South African time and I'm here in California, I had a go. The UTS Global Tape Subsystem includes the command tapevary(8), used mainly to vary online a tape drive to the system. So, tapevary on 3028 varies drive 3028 online. It causes the UTSG tape driver to perform an attach, and tapevary off 3028 performs an unattach. If I have 3028 varied online to one VM Linux and try to vary it online at another, the Drive Assigned Elsewhere message appears. So consider it verified, at least under VM. We had a power outrage, um, outage, today and besides I see no recognition in our driver's code that it's running under VM or LPAR, so I judge that tapevary on 3028 will issue an attach command regardless. Hope this is the verification you wanted. Richard Hitt [EMAIL PROTECTED] Jim Sibley wrote: Paul, have you physically verified that UTSG actually works this way on s/390 in both LPAR or under VM? Does it apply to ECKD shared tapes, not dedicated tapes? It the lock a UTSG lock or is it a hardware assign/unassign. Without the hardware assign/unassign, it is not really locked from other hosts in the s/390 environment. Minimally the UTSG Tape Management System will lock the drive(s) and manage tape mount requests, once tapes are mounted the UTSG driver makes the mounted tape accessible to user/app via a logical device named after the tape volume name. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
On Thu, 12 Jun 2003, Jim Sibley wrote: File open-to-close doesn't sound like a very useful paradigm (but I don't know how Linux applications use tape drives) and I don't know if one part of Linux can open a tape file (tape management system, just to lock the drive and to request a tape mount) and another part of Linux subsequently opening-writing/reading-closing the same tape so that the drive is not unassigned until the tape management system closes the tape file. The implementation is what you would expect for a shared printer, a write only device - during write, the device is dedicated and after the write, the data is no longer available. The assign is done at open/close time, I suspect if one applicaiton assigns the drive and leaves it assigned, then another application uses the drive, then the the assign would be dropped after the second app closes the file. As implemented, is dangerous for shared tape, as it does not allow time for operator intervention (loading/unloading the tape) before it is used by another hosts, and 2) two hosts could rewind and/or record to the same tape without knowing it. For example, tar is an applicaiton that can write to the tape directly and read it back. tar -cvpi -f /dev/ntibm0 some time later (during this time, another system could do a similar function) tar -xzpi -f /dev/ntibm0 results could be unpredictable or you might get someone elses data! That will _never_ work, even without another macine stuffing you up!! -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
On Thu, 12 Jun 2003, Jim Sibley wrote: Dave wrote: Methinks the Right Thing To Do would be to add function to mt to allow it to reserve a drive (eg, mt reserve /dev/st0) when a application wants on, and provide a release function when you're done with it (eg mt release /dev/st0). That would be generic enough to handle most of the Intel cases as well, but would suit us nicely(*). Since its really a zSeries notion, it seems to me putting the assign/unassign in insmod/delmod tape390 initialization somehow would be more appropriate. Also, the way the tapes have been implemented (by dev node), there is no mount involved. Mounts in linux don't really mount devices - they mount file systems. It's not at all clear to me that the fact you have tape390 loaded means you want to lock _all_ your tape drives. What if you decide on a custom kernel with tape390 builtin? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
John, please elucidate. Is the discussion incorrect or did I code the tar coding example incomplete? If so, what would you have coded? Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens *** John Summerfield [EMAIL PROTECTED]To: [EMAIL PROTECTED] afe.com.au cc: Sent by: Linux on 390Subject: Re: Linux390 + VM + Tape 3490 Port [EMAIL PROTECTED] EDU 06/12/2003 03:26 PM Please respond to Linux on 390 Port On Thu, 12 Jun 2003, Jim Sibley wrote: File open-to-close doesn't sound like a very useful paradigm (but I don't know how Linux applications use tape drives) and I don't know if one part of Linux can open a tape file (tape management system, just to lock the drive and to request a tape mount) and another part of Linux subsequently opening-writing/reading-closing the same tape so that the drive is not unassigned until the tape management system closes the tape file. The implementation is what you would expect for a shared printer, a write only device - during write, the device is dedicated and after the write, the data is no longer available. The assign is done at open/close time, I suspect if one applicaiton assigns the drive and leaves it assigned, then another application uses the drive, then the the assign would be dropped after the second app closes the file. As implemented, is dangerous for shared tape, as it does not allow time for operator intervention (loading/unloading the tape) before it is used by another hosts, and 2) two hosts could rewind and/or record to the same tape without knowing it. For example, tar is an applicaiton that can write to the tape directly and read it back. tar -cvpi -f /dev/ntibm0 some time later (during this time, another system could do a similar function) tar -xzpi -f /dev/ntibm0 results could be unpredictable or you might get someone elses data! That will _never_ work, even without another macine stuffing you up!! -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
On Thu, 12 Jun 2003, Richard Hitt wrote: Hi, Jim Since Paul's on South African time and I'm here in California, I had a go. The UTS Global Tape Subsystem includes the command tapevary(8), used mainly to vary online a tape drive to the system. So, tapevary on 3028 varies drive 3028 online. It causes the UTSG tape driver to perform an attach, and tapevary off 3028 performs an unattach. If I have 3028 varied online to one VM Linux and try to vary it online at another, the Drive Assigned Elsewhere message appears. So consider it verified, at least under VM. We had a power outrage, um, outage, today and besides I see no recognition in our driver's code that Hmm. Seems to me that zBoxes are dropping like flies;-) I was at an IBM presentation the other day, where they were talking about MTBF of decades. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
On Thu, 12 Jun 2003, Jim Sibley wrote: John, please elucidate. Is the discussion incorrect or did I code the tar coding example incomplete? If so, what would you have coded? ;-) In one tar command, but not the other, you have specified compression. I think on the S/390 and zeds I'd leave compression off: it takes too long in my brandxBoxes. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens *** John Summerfield [EMAIL PROTECTED]To: [EMAIL PROTECTED] afe.com.au cc: Sent by: Linux on 390Subject: Re: Linux390 + VM + Tape 3490 Port [EMAIL PROTECTED] EDU 06/12/2003 03:26 PM Please respond to Linux on 390 Port On Thu, 12 Jun 2003, Jim Sibley wrote: File open-to-close doesn't sound like a very useful paradigm (but I don't know how Linux applications use tape drives) and I don't know if one part of Linux can open a tape file (tape management system, just to lock the drive and to request a tape mount) and another part of Linux subsequently opening-writing/reading-closing the same tape so that the drive is not unassigned until the tape management system closes the tape file. The implementation is what you would expect for a shared printer, a write only device - during write, the device is dedicated and after the write, the data is no longer available. The assign is done at open/close time, I suspect if one applicaiton assigns the drive and leaves it assigned, then another application uses the drive, then the the assign would be dropped after the second app closes the file. As implemented, is dangerous for shared tape, as it does not allow time for operator intervention (loading/unloading the tape) before it is used by another hosts, and 2) two hosts could rewind and/or record to the same tape without knowing it. For example, tar is an applicaiton that can write to the tape directly and read it back. tar -cvpi -f /dev/ntibm0 some time later (during this time, another system could do a similar function) tar -xzpi -f /dev/ntibm0 results could be unpredictable or you might get someone elses data! That will _never_ work, even without another macine stuffing you up!! -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
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
Re: Linux390 + VM + Tape 3490
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
Re: Linux390 + VM + Tape 3490
On Thu, 12 Jun 2003, Fargusson.Alan wrote: 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. Why is the mt command the wrong place? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Linux390 + VM + Tape 3490
The mt command is designed to control a tape drive. An allocate command would be used to gain access to a tape drive, and prevent others from using it. Perhaps this seems like a fine point, but I prefer to separate the functionality. -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 5:25 PM To: [EMAIL PROTECTED] Subject: Re: Linux390 + VM + Tape 3490 On Thu, 12 Jun 2003, Fargusson.Alan wrote: 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. Why is the mt command the wrong place? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
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 onSubject: 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
Re: Linux390 + VM + Tape 3490
On Thu, Jun 12, 2003 at 05:31:39PM -0700, Fargusson.Alan wrote: The mt command is designed to control a tape drive. An allocate command would be used to gain access to a tape drive, and prevent others from using it. Perhaps this seems like a fine point, but I prefer to separate the functionality. I guess I'm puzzled about what the distinction is. Allocation (IMHO) seems to be a tape control function -- it's clearly discrete from reading and writing the data on the tape, and 'mt' contains every other function that is not directly related to reading and writing the tape. All mt does is execute ioctl's to control tape function, just like the TSO ALLOCATE command performs the standard allocation functions driven by a chunk of command line code. How is this any different?
Re: Linux390 + VM + Tape 3490
The UTS Global Tape Services Suite (TSS) for Linux/390 will accomplish this task, specifically the Tape Management Subsystem and Distributed Tape Subsystem products. Please see http://www.utsglobal.com/linuxprod.html for details. Feel free to contact me/us off-list if you require any further information. As Mark Post mentioned earlier, Phil's SHARE presentation on this subject is available at http://linuxvm.org/Present/ Paul.
Re: Linux390 + VM + Tape 3490
On Wednesday, 06/11/2003 at 08:50 ZE2, Paul Wilkinson [EMAIL PROTECTED] wrote: The UTS Global Tape Services Suite (TSS) for Linux/390 will accomplish this task, specifically the Tape Management Subsystem and Distributed Tape Subsystem products. Please see http://www.utsglobal.com/linuxprod.html for details. Feel free to contact me/us off-list if you require any further information. As Mark Post mentioned earlier, Phil's SHARE presentation on this subject is available at http://linuxvm.org/Present/ If the driver handles the assign/unassign in a reasonble way, then z/VM 4.3's shared tape support (CP ATTACH ... MULTIUSER...) allows multiple guests to share a tape drive without having to ATTACH/DETACH it. By reasonable I mean that drive assignment is done only for the duration of tape, not drive, usage. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
Please, Alan, could you explain me, what do you mean in a reasonable way? I don't understand the difference between Tape usage and drive usage. And sorry, I don't want to spend your time. Ariel El mii, 11 de 06 de 2003 a las 16:33, Alan Altmark escribis: On Wednesday, 06/11/2003 at 08:50 ZE2, Paul Wilkinson [EMAIL PROTECTED] wrote: The UTS Global Tape Services Suite (TSS) for Linux/390 will accomplish this task, specifically the Tape Management Subsystem and Distributed Tape Subsystem products. Please see http://www.utsglobal.com/linuxprod.html for details. Feel free to contact me/us off-list if you require any further information. As Mark Post mentioned earlier, Phil's SHARE presentation on this subject is available at http://linuxvm.org/Present/ If the driver handles the assign/unassign in a reasonble way, then z/VM 4.3's shared tape support (CP ATTACH ... MULTIUSER...) allows multiple guests to share a tape drive without having to ATTACH/DETACH it. By reasonable I mean that drive assignment is done only for the duration of tape, not drive, usage. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Linux390 + VM + Tape 3490
Alan, shared tapes may have a problem under VM. I know they do when running in an LPAR (see the disclaimer on the IBM under restrictions at http://www10.software.ibm.com/developerworks/opensource/linux390/index.shtml ). The assign/unassign function is not implemented the same way in Linux as in other OS. - For MVS, the drive assign latch is set from vary online to vary offline. - For VM, the drive assign latch is set from attach to detach (for tapes single tapes) - In LPAR mode, for SLES7 - the assign latch is not set at all so several lpars can send commands to the tape at the same time! - In LPAR mode, for SLES8 - the assign latch is only set during the time from OPEN to CLOSE of the file. After the file is closed by one LPAR, it can be stolen by another LPAR. So I would guess that assign ... muiltiuser would have the same problems as an LPAR. The latch should be set from the INSMOD to the DELMOD, but it is NOT, hence the strong recommendations for 2.2.16, and both streams of 2.4 NOT to use shared tapes. The CP attach multiuser sounds like it relies on the hardware assign/unassign and you could find yourself with two EC's using the tape at the same time under Linux. We have verified that, in LPAR mode, the assign happening as I described. Correct me if I am wrong if VM assign ... multipath uses a different mechanism. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Linux390 + VM + Tape 3490
On Wed, 11 Jun 2003, Kennedy Ariel wrote: Hello : I have 6 Linux machines running on a VM environment and I have only one tape 3490. How can I share this Tape Unit between all these Linux machines? In which way can I make these all Linux machines to see and share the tape unit? Regards from Ariel, and please sorry about my english. Tar and most other backup utilities support remote tape drives. It does involve sending the data over the network. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
