bill@franklin.com (Bill) (09/08/90)
Hi, I have a question, or rather several. I just recently wrote myself a RAM disk driver for my system for use with /tmp. (Why do I want a RAM disk? After much tuning, I find that my system, a SysV3.0, spends most of its time under load doing disk related stuff. I have cycles and memory to spare, however.) There are (at least) two defects with this. The first is that /tmp is not the only directory that I'd like to put into the RAM disk; I'd also like to put in /usr/tmp and maybe /usr/spool/locks and I'm sure I could find a few others that could be usefully made to go there. Well, the only solution I could think of (remember, this is SysV, no symbolic links), is to create several device files, each pointing to the same RAM disk and to mount each separately. (No, I don't want several RAM disks!) If I do this, there are obviously some utilities that will get a bit confused, e.g., find would scan the directories more than once, but is there anything that will outright break? I can't think of anything, but I'm only a guru-in-training. :-) The second is that a fixed RAM disk is really brainless. There's all that memory off on its own, not usable for anything else. I'd really like to be able to integrate the RAM disk with the block buffering system, so that the RAM disk would have its allocated blocks come out of the pool. Does anyone know of any reason why that could not be made to work? Or even if someone has done something like that? For my final question: The whole purpose of the RAM disk is to better utilize my system. I have scads of memory, a reasonably fast CPU, slow disks :-(, and SysV3.0 :-(. I'm not rich enough to change either of those negatives by applying money, so I have to get around them another way. Does anyone have any other suggestions on eliminating the disk bottleneck?
peter@ficc.ferranti.com (Peter da Silva) (09/08/90)
You might want to try implementing redirects, as found in Intel's OpenNET for System V. Basically, before namei gets cracking on a file name it's compared against a list of prefixes. If it's found, that part of the filename is replaced by the redirected text. I don't know how they do this as a driver, but it's all handled by nfa/Driver.o. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
ikluft@uts.amdahl.com (Ian Kluft) (09/11/90)
In article <900908.7074@franklin.com> bill@franklin.com (Bill) writes: >I have a question, or rather several. I just recently wrote myself >a RAM disk driver for my system for use with /tmp. [...] > >The first is that /tmp is not the only directory that I'd like to >put into the RAM disk; I'd also like to put in /usr/tmp and maybe >/usr/spool/locks and I'm sure I could find a few others that >could be usefully made to go there. Well, the only solution I >could think of (remember, this is SysV, no symbolic links), is to >create several device files, each pointing to the same RAM disk >and to mount each separately. (No, I don't want several RAM >disks!) >[...] We have had a similar situation here with "shared DASD" (multi-ported disks accessed by several mainframes running UTS). Basically, any number of systems can have the file system mounted read-only but only one can have it read/write. I believe that even with a RAMdisk accessed by one system, multiple mount points for the same device would have to be treated the same way because you can confuse the kernel. Unwritten buffers can make each mount point out of sync. Since you're posting from a commercial site, I think you'd be best off to take the conservative route (multiple RAMdisks) so that your organization can continue to count on the system's reliability. -- Ian Kluft UTS Systems Software, Amdahl Corporation ikluft@uts.amdahl.com Santa Clara, CA **** UTS == System V for mainframes and power users ****
dvv@hq.demos.su (Dmitry V. Volodin) (09/12/90)
In article <900908.7074@franklin.com> bill@franklin.com (Bill) writes: > > ... >have cycles and memory to spare, however.) There are (at least) You'd better increase the size of your cache pool. The effect is much better. Folks, does anyone want to discuss the pros and cons of placing the swap/pageing area onto the ram disk? :) -- ------------------------------------+------------------------------ Dmitry V. Volodin | internet: <dvv@hq.demos.su> | or <dvv%hq.demos.su@fuug.fi> | Motto coming soon.
chris@mimsy.umd.edu (Chris Torek) (09/13/90)
In article <1990Sep12.084002.5575@hq.demos.su> dvv@hq.demos.su (Dmitry V. Volodin) writes: >You'd better increase the size of your cache pool. The effect is much >better. Well, yes and no: one of the real benefits of a RAM /tmp is that file creation and deletion are synchronous operations, and they go a lot faster when waiting for RAM rather than a disk. :-) This is why 4.3BSD-reno has the virtual memory file system type. VMFSes use RAM when it is available, or backing store (swap space) otherwise. Note that you must change vi to store its temporary files on a real disk so that it can recover edit sessions after power failures, etc. (I realize you Californians do not have daily power failures every summer like those of us on the east coast.... Thunderstorms, is why.) >Folks, does anyone want to discuss the pros and cons of placing the >swap/pageing area onto the ram disk? :) Although this was not intended seriously, there are some Unix kernels out there where this would help. Ten years ago some of the popular machines (VAX-11/780...) were better at DMA I/O than cpu-mediated memory-to-memory copies, and therefore a number of operations were done using the paging area as a sort of memory-to-memory DMA device. This is supposed to be fixed Real Soon Now. >internet: <dvv@hq.demos.su> Do svedanya, <- will this get me into the NSA archives? :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris