SysVInit v.0.4 released
Now with more enemy-counfounding power than ever before, and at least 5% more friend amazement! Version 0.4 of SysVInit for z/VM and VM/ESA is available at: http://www.sinenomine.net/vm/s5i This release contains the LIST RUNLEVELS command, as well as SERVICE ADD/REMOVE. With the latter two, unless you need to change the provided SVM EXEC (which works just fine in most cases), you no longer need to link the SysVInit configuration disk in order to specify new services; SERVICE foo ADD copies SVM EXEC to foo EXEC. No points for guessing what SERVICE REMOVE does. The documentation has also been updated. The *next* release will add a user tool that functions rather like Linux's chkconfig, which will make adding new services via an installer much easier; I think I finally have all the pieces in place I need to support that. Enjoy! Adam -- 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
Re: [Possible Spam] Re: Linux LPAR - how to drop caching
If you are correct and it can be done at the filesystem level, then maybe you don't even have to write a whole new one. I recall reading about the new ReiserFS 4 being modular, maybe you could just write a plugin. -jmc On Fri, 17 Sep 2004 09:06:18 -0700 "Fargusson.Alan" <[EMAIL PROTECTED]> wrote: > It occurs to me that since the filesystem is what actually controls the buffer cache > that one could write a filesystem for Linux on VM that ignores the buffer cache and > does logical IOCS. Or maybe you need a DASD driver that does logical IOCS. The > filesystem would probably need to do something about mmap and fault loading, but it > could be done. > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Ward, Garry > Sent: Friday, September 17, 2004 8:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [Possible Spam] Re: Linux LPAR - how to drop caching > > > This takes us back to the wonderful world of Logical IOCS vs Physical IOCS. In the > Mainframe world there as always been a diference between Logical I/O (the program's > write of 80 bytes) and the Physical I/O (the writing of a 4K data block to a device > by an operating system). In the PC world where Linux grew up, there has never been > such a divide and it has been handled by device drivers and cache. > > Granted, trying to make Linux truely handle Logical vs Physical I/O in the way that > VSE, MVS Or VM handles it may not be possible or just very, very hard. However, > giving Linux a means to install with full normal PC style cache or to install with a > VM friendly adjustable/limitable cache would be nice. > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Fargusson.Alan > Sent: Friday, September 17, 2004 11:35 AM > To: [EMAIL PROTECTED] > Subject: [Possible Spam] Re: Linux LPAR - how to drop caching > > > This has nothing to do with the "everything is a file" philosophy. It has to do > with the fact that most *ix systems don't have a layer below them to do buffering. > Actually even when you do the overhead of calling down to the driver for every write > would kill some systems. > > Think about a program that writes 80 bytes at a time to a large file. Each 80 byte > write would involve going to VM each time. Suppose the block size is 4096 bytes > (which is usually true) you would be doing 52 calls to VM without *ix buffering, > while you only do one call to VM for each 4096 bytes with buffering. Reducing the > number of calls to the driver by 52 times is a big win on some systems. > > There are other reasons for having the buffer cache embedded the way it is, but I > don't want to get too long wended. > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Phil Smith III > Sent: Friday, September 17, 2004 4:13 AM > To: [EMAIL PROTECTED] > Subject: Re: Linux LPAR - how to drop caching > > > Ranga Nathan <[EMAIL PROTECTED]> wrote: > >We are on STK V2X DASD array. We can do very well without Linux adding > >further caching. Is there a way to tell Linux not to cache the DASD? > > As David said, there's apparently no way to turn this off. For several > years, I've been asking folks this same question. "You can't", they'd say. > "But you keep saying, 'You can do anything, it's Linux!'", I'd respond. > > After saying that several times, I finally got an explanation that I think > makes sense: this is a result of *ix's "everything is a file" philosophy. > By the time the request gets down low enough in the OS that it hits the > caching code, the fact that a page is from disk is long lost. > > That doesn't mean it couldn't be fixed (yes, I'm using the word "fixed" -- I > see this as a serious design flaw, from a shared storage standpoint), just > that it's non-trivial. > > HTH > > ...phsiii > > -- > 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 > > -- > 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 > > > 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
Re: VM Setup
Thanks for all the info. >>> [EMAIL PROTECTED] 9/17/2004 1:10:27 PM >>> Or look at his very good presentation on the subject at http://www.vm.ibm.com/devpages/altmarka/s9233a.pdf Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter Webb, Toronto Transit Commission Sent: Friday, September 17, 2004 1:06 PM To: [EMAIL PROTECTED] Subject: Re: VM Setup To do this, you need to enable PROXY ARP on VM TCP/IP. Check the VM list archive http://listserv.uark.edu/archives/vmesa-l.html for posts from Alan Altmark on PROXY ARP for intelligent explanations. -- 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 -- 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
Re: VM Setup
Or look at his very good presentation on the subject at http://www.vm.ibm.com/devpages/altmarka/s9233a.pdf Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter Webb, Toronto Transit Commission Sent: Friday, September 17, 2004 1:06 PM To: [EMAIL PROTECTED] Subject: Re: VM Setup To do this, you need to enable PROXY ARP on VM TCP/IP. Check the VM list archive http://listserv.uark.edu/archives/vmesa-l.html for posts from Alan Altmark on PROXY ARP for intelligent explanations. -- 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
Re: VM Setup
To do this, you need to enable PROXY ARP on VM TCP/IP. Check the VM list archive http://listserv.uark.edu/archives/vmesa-l.html for posts from Alan Altmark on PROXY ARP for intelligent explanations. -Original Message- From: Doug Griswold [mailto:[EMAIL PROTECTED] Sent: September 17, 2004 12:57 To: [EMAIL PROTECTED] Subject: Re: VM Setup The Suse VM is on the same subnet on the same switch and is using ctc. I believe our vm guy is going to try guest lan now. You have to excuse my acsii art. _ | NFS | ---| |_10.1.1.6| | | | | suse vm | | 10.1.1.5 | | ---| | switched network || 255.255.255.0 vm 10.1.1.4 __| | | The VM guy just told me he hasn't configured Proxy ARP as well. >>> [EMAIL PROTECTED] 9/17/2004 12:28:31 PM >>> On Fri, 2004-09-17 at 10:54, Doug Griswold wrote: > Thanks for verifying that. So here is what I'm currently seeing. > During the install I can see the Linux installer pinging my nfs server > and it replys back but never reaches my Suse VM. I put a static route > in the nfs server to point to the VM4.3 machine for the IP of the Suse > install. This didn't help. All of these machines are in the same > subnet (suse install, nfs server, and VM4.3). It looks to me that VM > might not be passing it to the Suse install. Same subnet? Are they on a guest LAN, or on CTC? If they're on CTC, that's your problem right there: there should only be a point-to-point connection, with netmasks of 255.255.255.255. If there's a subnet defined then everything probably thinks it can talk to everything else directly, which it can't: it's gotta go through VM. Is your NFS server another Linux virtual machine, or a desktop system, or what? Can you draw an ASCII picture of your network setup and who has which IP address and (importantly) netmask? That might help me figure out what you're seeing. Adam -- 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 -- 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 __ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on the basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. -- 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
Re: VM Setup
The Suse VM is on the same subnet on the same switch and is using ctc. I believe our vm guy is going to try guest lan now. You have to excuse my acsii art. _ | NFS | ---| |_10.1.1.6| | | | | suse vm | | 10.1.1.5 | | ---| | switched network || 255.255.255.0 vm 10.1.1.4 __| | | The VM guy just told me he hasn't configured Proxy ARP as well. >>> [EMAIL PROTECTED] 9/17/2004 12:28:31 PM >>> On Fri, 2004-09-17 at 10:54, Doug Griswold wrote: > Thanks for verifying that. So here is what I'm currently seeing. > During the install I can see the Linux installer pinging my nfs server > and it replys back but never reaches my Suse VM. I put a static route > in the nfs server to point to the VM4.3 machine for the IP of the Suse > install. This didn't help. All of these machines are in the same > subnet (suse install, nfs server, and VM4.3). It looks to me that VM > might not be passing it to the Suse install. Same subnet? Are they on a guest LAN, or on CTC? If they're on CTC, that's your problem right there: there should only be a point-to-point connection, with netmasks of 255.255.255.255. If there's a subnet defined then everything probably thinks it can talk to everything else directly, which it can't: it's gotta go through VM. Is your NFS server another Linux virtual machine, or a desktop system, or what? Can you draw an ASCII picture of your network setup and who has which IP address and (importantly) netmask? That might help me figure out what you're seeing. Adam -- 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 -- 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
Re: VM Setup
Is PROXY ARP enabled in VM TCP/IP? -Original Message- From: Doug Griswold [mailto:[EMAIL PROTECTED] Sent: September 17, 2004 11:54 To: [EMAIL PROTECTED] Subject: Re: VM Setup Thanks for verifying that. So here is what I'm currently seeing. During the install I can see the Linux installer pinging my nfs server and it replys back but never reaches my Suse VM. I put a static route in the nfs server to point to the VM4.3 machine for the IP of the Suse install. This didn't help. All of these machines are in the same subnet (suse install, nfs server, and VM4.3). It looks to me that VM might not be passing it to the Suse install. Thanks >>> [EMAIL PROTECTED] 9/17/2004 10:32:53 AM >>> On Fri, 2004-09-17 at 08:34, Doug Griswold wrote: > I have one more question. In a ctc connection when going through the > install the "Peer IP Address" is the address of the VM instance? Yes. > Also > how do I get out of the mainframe if this is a point to point > connection? Does VM have to route me out to the default gateway? Yes. And this is probably your problem. VM is likely to already be routing you out, but whatever is upstream of VM in the network doesn't know that to get to your address it has to go through VM. Either your network guys will have to configure a static route, or they will have to accept dynamic routing updates from VM and VM will have to announce the route to your Linux guest. The CTC itself is (from the Linux perspective) simply a point-to-point IP link; think of it like dialup PPP if you like. If you're running z/VM 4.2 with recent service or anything later, you probably want to use Guest LANs instead, as they're a lot more like just working with an Ethernet adapter. Adam -- 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 -- 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 __ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on the basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. -- 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
Re: VM Setup
On Fri, 2004-09-17 at 10:54, Doug Griswold wrote: > Thanks for verifying that. So here is what I'm currently seeing. > During the install I can see the Linux installer pinging my nfs server > and it replys back but never reaches my Suse VM. I put a static route > in the nfs server to point to the VM4.3 machine for the IP of the Suse > install. This didn't help. All of these machines are in the same > subnet (suse install, nfs server, and VM4.3). It looks to me that VM > might not be passing it to the Suse install. Same subnet? Are they on a guest LAN, or on CTC? If they're on CTC, that's your problem right there: there should only be a point-to-point connection, with netmasks of 255.255.255.255. If there's a subnet defined then everything probably thinks it can talk to everything else directly, which it can't: it's gotta go through VM. Is your NFS server another Linux virtual machine, or a desktop system, or what? Can you draw an ASCII picture of your network setup and who has which IP address and (importantly) netmask? That might help me figure out what you're seeing. Adam -- 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
Re: [Possible Spam] Re: Linux LPAR - how to drop caching
> > This takes us back to the wonderful world of Logical IOCS vs Physical IOCS. In the > Mainframe world there as always been a diference between Logical I/O (the program's > write of 80 bytes) and the Physical I/O (the writing of a 4K data block to a device > by an operating system). In the PC world where Linux grew up, there has never been > such a divide and it has been handled by device drivers and cache. At least for disk I/O you DO have "sort of" the same concept available to you: your program calls a "library routine" (aka access method), which passes it to a device driver, which then sends a command to the SCSI controller (psuedo EXCP), which puts a command on the SCSI bus (SIO?). I'm not saying things are equivalent, but there are parallel concepts involved. Later on, the concept of asynch. I/O was surfaced which enables an application programmer to start an I/O and check on the outcome later on. The point is that as things like SCSI controllers get "smarter" and more powerful, then the application and OS developers can take advantage of these features. I know, I know: the XA architecture is 20+ years old, but these guys are catching up, just be patient. :) -- 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
Re: VM Setup
No, it's the routers between you and the VM system. Unless that last router has a static route in it to pass the packet to the VM system, it will try to do an arp. When it gets no reply, it will drop the packet. This is because the IP address is in the same subnet as the router's NIC, so it will assume that the system will be able to hear the arp and reply. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Doug Griswold Sent: Friday, September 17, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: Re: VM Setup Thanks for verifying that. So here is what I'm currently seeing. During the install I can see the Linux installer pinging my nfs server and it replys back but never reaches my Suse VM. I put a static route in the nfs server to point to the VM4.3 machine for the IP of the Suse install. This didn't help. All of these machines are in the same subnet (suse install, nfs server, and VM4.3). It looks to me that VM might not be passing it to the Suse install. Thanks >>> [EMAIL PROTECTED] 9/17/2004 10:32:53 AM >>> On Fri, 2004-09-17 at 08:34, Doug Griswold wrote: > I have one more question. In a ctc connection when going through the > install the "Peer IP Address" is the address of the VM instance? Yes. > Also > how do I get out of the mainframe if this is a point to point > connection? Does VM have to route me out to the default gateway? Yes. And this is probably your problem. VM is likely to already be routing you out, but whatever is upstream of VM in the network doesn't know that to get to your address it has to go through VM. Either your network guys will have to configure a static route, or they will have to accept dynamic routing updates from VM and VM will have to announce the route to your Linux guest. The CTC itself is (from the Linux perspective) simply a point-to-point IP link; think of it like dialup PPP if you like. If you're running z/VM 4.2 with recent service or anything later, you probably want to use Guest LANs instead, as they're a lot more like just working with an Ethernet adapter. Adam -- 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 -- 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 -- 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
Re: [Possible Spam] Re: Linux LPAR - how to drop caching
It occurs to me that since the filesystem is what actually controls the buffer cache that one could write a filesystem for Linux on VM that ignores the buffer cache and does logical IOCS. Or maybe you need a DASD driver that does logical IOCS. The filesystem would probably need to do something about mmap and fault loading, but it could be done. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ward, Garry Sent: Friday, September 17, 2004 8:45 AM To: [EMAIL PROTECTED] Subject: Re: [Possible Spam] Re: Linux LPAR - how to drop caching This takes us back to the wonderful world of Logical IOCS vs Physical IOCS. In the Mainframe world there as always been a diference between Logical I/O (the program's write of 80 bytes) and the Physical I/O (the writing of a 4K data block to a device by an operating system). In the PC world where Linux grew up, there has never been such a divide and it has been handled by device drivers and cache. Granted, trying to make Linux truely handle Logical vs Physical I/O in the way that VSE, MVS Or VM handles it may not be possible or just very, very hard. However, giving Linux a means to install with full normal PC style cache or to install with a VM friendly adjustable/limitable cache would be nice. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Fargusson.Alan Sent: Friday, September 17, 2004 11:35 AM To: [EMAIL PROTECTED] Subject: [Possible Spam] Re: Linux LPAR - how to drop caching This has nothing to do with the "everything is a file" philosophy. It has to do with the fact that most *ix systems don't have a layer below them to do buffering. Actually even when you do the overhead of calling down to the driver for every write would kill some systems. Think about a program that writes 80 bytes at a time to a large file. Each 80 byte write would involve going to VM each time. Suppose the block size is 4096 bytes (which is usually true) you would be doing 52 calls to VM without *ix buffering, while you only do one call to VM for each 4096 bytes with buffering. Reducing the number of calls to the driver by 52 times is a big win on some systems. There are other reasons for having the buffer cache embedded the way it is, but I don't want to get too long wended. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Phil Smith III Sent: Friday, September 17, 2004 4:13 AM To: [EMAIL PROTECTED] Subject: Re: Linux LPAR - how to drop caching Ranga Nathan <[EMAIL PROTECTED]> wrote: >We are on STK V2X DASD array. We can do very well without Linux adding >further caching. Is there a way to tell Linux not to cache the DASD? As David said, there's apparently no way to turn this off. For several years, I've been asking folks this same question. "You can't", they'd say. "But you keep saying, 'You can do anything, it's Linux!'", I'd respond. After saying that several times, I finally got an explanation that I think makes sense: this is a result of *ix's "everything is a file" philosophy. By the time the request gets down low enough in the OS that it hits the caching code, the fact that a page is from disk is long lost. That doesn't mean it couldn't be fixed (yes, I'm using the word "fixed" -- I see this as a serious design flaw, from a shared storage standpoint), just that it's non-trivial. HTH ...phsiii -- 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 -- 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 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. -- 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 -- For LINUX-390 subscribe / signoff / archive access instructions, send ema
Re: VM Setup
Thanks for verifying that. So here is what I'm currently seeing. During the install I can see the Linux installer pinging my nfs server and it replys back but never reaches my Suse VM. I put a static route in the nfs server to point to the VM4.3 machine for the IP of the Suse install. This didn't help. All of these machines are in the same subnet (suse install, nfs server, and VM4.3). It looks to me that VM might not be passing it to the Suse install. Thanks >>> [EMAIL PROTECTED] 9/17/2004 10:32:53 AM >>> On Fri, 2004-09-17 at 08:34, Doug Griswold wrote: > I have one more question. In a ctc connection when going through the > install the "Peer IP Address" is the address of the VM instance? Yes. > Also > how do I get out of the mainframe if this is a point to point > connection? Does VM have to route me out to the default gateway? Yes. And this is probably your problem. VM is likely to already be routing you out, but whatever is upstream of VM in the network doesn't know that to get to your address it has to go through VM. Either your network guys will have to configure a static route, or they will have to accept dynamic routing updates from VM and VM will have to announce the route to your Linux guest. The CTC itself is (from the Linux perspective) simply a point-to-point IP link; think of it like dialup PPP if you like. If you're running z/VM 4.2 with recent service or anything later, you probably want to use Guest LANs instead, as they're a lot more like just working with an Ethernet adapter. Adam -- 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 -- 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
Re: [Possible Spam] Re: Linux LPAR - how to drop caching
This takes us back to the wonderful world of Logical IOCS vs Physical IOCS. In the Mainframe world there as always been a diference between Logical I/O (the program's write of 80 bytes) and the Physical I/O (the writing of a 4K data block to a device by an operating system). In the PC world where Linux grew up, there has never been such a divide and it has been handled by device drivers and cache. Granted, trying to make Linux truely handle Logical vs Physical I/O in the way that VSE, MVS Or VM handles it may not be possible or just very, very hard. However, giving Linux a means to install with full normal PC style cache or to install with a VM friendly adjustable/limitable cache would be nice. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Fargusson.Alan Sent: Friday, September 17, 2004 11:35 AM To: [EMAIL PROTECTED] Subject: [Possible Spam] Re: Linux LPAR - how to drop caching This has nothing to do with the "everything is a file" philosophy. It has to do with the fact that most *ix systems don't have a layer below them to do buffering. Actually even when you do the overhead of calling down to the driver for every write would kill some systems. Think about a program that writes 80 bytes at a time to a large file. Each 80 byte write would involve going to VM each time. Suppose the block size is 4096 bytes (which is usually true) you would be doing 52 calls to VM without *ix buffering, while you only do one call to VM for each 4096 bytes with buffering. Reducing the number of calls to the driver by 52 times is a big win on some systems. There are other reasons for having the buffer cache embedded the way it is, but I don't want to get too long wended. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Phil Smith III Sent: Friday, September 17, 2004 4:13 AM To: [EMAIL PROTECTED] Subject: Re: Linux LPAR - how to drop caching Ranga Nathan <[EMAIL PROTECTED]> wrote: >We are on STK V2X DASD array. We can do very well without Linux adding >further caching. Is there a way to tell Linux not to cache the DASD? As David said, there's apparently no way to turn this off. For several years, I've been asking folks this same question. "You can't", they'd say. "But you keep saying, 'You can do anything, it's Linux!'", I'd respond. After saying that several times, I finally got an explanation that I think makes sense: this is a result of *ix's "everything is a file" philosophy. By the time the request gets down low enough in the OS that it hits the caching code, the fact that a page is from disk is long lost. That doesn't mean it couldn't be fixed (yes, I'm using the word "fixed" -- I see this as a serious design flaw, from a shared storage standpoint), just that it's non-trivial. HTH ...phsiii -- 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 -- 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 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. -- 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
Re: Can RMF PM send alerts?
Yes. Look at the example in chapter 7 of the PerfKit documentation on using action routines when a message matches a template, or in the session on setting thresholds. The action routine can do pretty much anything. PerfKit makes a really nice scrolling console manager. Almost as cool as VM:Operator. --d b > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Kohrs, Steven > Sent: Friday, September 17, 2004 9:49 AM > To: [EMAIL PROTECTED] > Subject: Can RMF PM send alerts? > > > Is it possible to send notifications from RMF PM or z/VM Performance > Toolkit when thresholds are surpassed? -- 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
Re: Linux LPAR - how to drop caching
This has nothing to do with the "everything is a file" philosophy. It has to do with the fact that most *ix systems don't have a layer below them to do buffering. Actually even when you do the overhead of calling down to the driver for every write would kill some systems. Think about a program that writes 80 bytes at a time to a large file. Each 80 byte write would involve going to VM each time. Suppose the block size is 4096 bytes (which is usually true) you would be doing 52 calls to VM without *ix buffering, while you only do one call to VM for each 4096 bytes with buffering. Reducing the number of calls to the driver by 52 times is a big win on some systems. There are other reasons for having the buffer cache embedded the way it is, but I don't want to get too long wended. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Phil Smith III Sent: Friday, September 17, 2004 4:13 AM To: [EMAIL PROTECTED] Subject: Re: Linux LPAR - how to drop caching Ranga Nathan <[EMAIL PROTECTED]> wrote: >We are on STK V2X DASD array. We can do very well without Linux adding >further caching. Is there a way to tell Linux not to cache the DASD? As David said, there's apparently no way to turn this off. For several years, I've been asking folks this same question. "You can't", they'd say. "But you keep saying, 'You can do anything, it's Linux!'", I'd respond. After saying that several times, I finally got an explanation that I think makes sense: this is a result of *ix's "everything is a file" philosophy. By the time the request gets down low enough in the OS that it hits the caching code, the fact that a page is from disk is long lost. That doesn't mean it couldn't be fixed (yes, I'm using the word "fixed" -- I see this as a serious design flaw, from a shared storage standpoint), just that it's non-trivial. HTH ...phsiii -- 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 -- 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
Re: VM Setup
On Fri, 2004-09-17 at 08:34, Doug Griswold wrote: > I have one more question. In a ctc connection when going through the > install the "Peer IP Address" is the address of the VM instance? Yes. > Also > how do I get out of the mainframe if this is a point to point > connection? Does VM have to route me out to the default gateway? Yes. And this is probably your problem. VM is likely to already be routing you out, but whatever is upstream of VM in the network doesn't know that to get to your address it has to go through VM. Either your network guys will have to configure a static route, or they will have to accept dynamic routing updates from VM and VM will have to announce the route to your Linux guest. The CTC itself is (from the Linux perspective) simply a point-to-point IP link; think of it like dialup PPP if you like. If you're running z/VM 4.2 with recent service or anything later, you probably want to use Guest LANs instead, as they're a lot more like just working with an Ethernet adapter. Adam -- 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
Can RMF PM send alerts?
Is it possible to send notifications from RMF PM or z/VM Performance Toolkit when thresholds are surpassed? -- 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
VM Setup
We are finally going to install Linux on top of VM but we have run into a small communication problem. We can't seem to get communications out of the Mainframe. I can ping VM from the Suse installer and I can ping myself. We are using a CTC connection. This should be a fairly easy problem to figure out but I'm not the VM guy I'm only doing the Linux side of things. Can you guys give me any pointers I can pass to our VM guy? I have one more question. In a ctc connection when going through the install the "Peer IP Address" is the address of the VM instance? Also how do I get out of the mainframe if this is a point to point connection? Does VM have to route me out to the default gateway? As you can tell I'm a little confused on CTC. Thanks, Doug -- 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
Re: Off charter - Mickeysoft
> Phil, that's a normal idiotic diagnostic message. It's also written to be as insulting as possible to the user. For myself IE has been throwing those for a longish while now. Office products have been behaving themselves for a while now. http://www.isham-research.com/dd.html - see "error mesage" > Oh, and what sound did your error make? Mine swore in the language and phrasing normally used by one Picard. I normally run with sound off. This is a laptop and I'm fairly mobile with it - it gets irritating for fellow-passengers on planes. > And yes I am aware of that blurb, just not its contents. IDG is about the only consulting and reporting firm, that comes close to making sense. One other firm whose name I won't mention doesn't. Should I be worried? > On another note, how's the weather where you are? And where's that so I can properly fix it in my mind. Today I'm at my usual base in Sheffield, England. The weather is all over the place and makes no sense at all - we've just had the wettest August since records began over a century ago - we alternate brilliant sunny days and vicious storms dumping inches of rain at a time. Search http://news.google.com for "Boscastle". It ain't terrorism that's gonna wipe out the human race. The planet's gonna do it. -- Phil Payne http://www.isham-research.com +44 7785 302 803 -- 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
Re: Linux LPAR - how to drop caching
Ranga Nathan <[EMAIL PROTECTED]> wrote: >We are on STK V2X DASD array. We can do very well without Linux adding >further caching. Is there a way to tell Linux not to cache the DASD? As David said, there's apparently no way to turn this off. For several years, I've been asking folks this same question. "You can't", they'd say. "But you keep saying, 'You can do anything, it's Linux!'", I'd respond. After saying that several times, I finally got an explanation that I think makes sense: this is a result of *ix's "everything is a file" philosophy. By the time the request gets down low enough in the OS that it hits the caching code, the fact that a page is from disk is long lost. That doesn't mean it couldn't be fixed (yes, I'm using the word "fixed" -- I see this as a serious design flaw, from a shared storage standpoint), just that it's non-trivial. HTH ...phsiii -- 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
