Xref: utzoo comp.unix.internals:839 alt.religion.computers:1974 Path: utzoo!attcan!lsuc!xenitec!maytag!watmath!att!att!mcdchg!ddsw1!proxima!ctk1!chris From: chris@ctk1.UUCP (Chris Old) Newsgroups: comp.unix.internals,alt.religion.computers Subject: Re^2: RAM disk. Message-ID: <1990Oct17.083948.1393@ctk1.UUCP> Date: 17 Oct 90 08:39:48 GMT References: <18574@rpp386.cactus.org> <1850@necisa.ho.necisa.oz> <1990Oct11.185949.29164@iconsys.uucp> <6372@titcce.cc.titech.ac.jp> Organization: Tran Systems Lines: 40 mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <1990Oct11.185949.29164@iconsys.uucp> > malc@iconsys.uucp (Malcolm Weir) writes: >>Really? just how do you persuade *nix to cache "/lib/*", in prefence to >>Joe Unimportant-User's huge statistical jobs that have been munging vast >>amounts of data for the past 12 days? >As /lib is almost readonly, I recommend you to tune BSD file system >parameters such as maxcontig with appropriate disk controllers. >Then, you can read entire /lib/libc.a with a single seek. Can you do this on Sys5? >>How do you persuade it that the >>disk accesses caused by the backup of "/irrelevant" are less important than >>the accesses caused by the CEO's secretary's WP temp files? >CEO's secretary should have his own workstation, of course. Get real. >>(btw, I used to be anti-RAM-disk, 'till I tried a system with "/lib" >> on RAM. "/tmp" didn't make that much difference, but you should've >> seen "ld" fly... ) >If you are using your own workstation with large memory and dynamic >buffer caching, you can observe the same thing. What a silly remark. We are not talking about how we can speed up things by throwing money at them, we are talking about how we can improve performance of an _existing_ configuration. -------------------- Chris Old (C.t.K.) | ddsw1!olsa99!ctk1!chris Tran Systems Ltd | olsa99!ctk1!chris@ddsw1.mcs.com If you have no reason for your opinion, change it.