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 email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
