| PLEX86 | ||
|
Re:tmp file in RAM 4443Re:tmp file in RAM 4444 Jean-David Beyer I think you are correct. Right now in I have atmp link todev... CWO4 Dave Mann catzcat vs bzcat do different things... AKA "bzcat is broken As long as some data is available, a read() call will return that amount of data immediately, even if it is less than the amount... I have 4 GBytes of RAM, but I would never placetmp in memory. Does your system load thetmp files with so much IO traffic that this would actually be faster than just allowing the Linux memory manager, IO buffering and IO caching system to manage the memory? In the general case I would imagine not. Remember the old rule: The more you try to outsmart an operating system, the more it will outsmart you. It depends on your useage oftmp, how you haveetc-cron.daily-tmpwatch configured, etc. Mine is almost 8 weeks 24-7, but that is no big deal. I had it up to about 6 months when I decided to give Red Hat Linux 7.3 a retirement (expecting to install Fedora Core 2 that did not work very well), and "upgrading" to Red Hat Linux 9 (that was already discontinued, but newer than RHL7.3). First of all, consider leavingtmp on disk unless you have already done a performance evaluation that clearly shows that IO totmp is a significant factor AND that putting it in memory clearly is faster. With all the caching and buffering of the IO system inherent in Linux, I doubt you could show this, except in unusual specific cases. If, as I suspect, you have a nonexistent problem, you could just stop this, and then would not have to add the complexity of cron jobs to clean out thetmp file system in RAM. Usually, simpler is better. -- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 15:20:00 up 55 days, 9:14, 3 users, load average: 4.28, 4.30, 4.22
|
||||
Linux groups from Newsgroups The #1 Usenet Provider on the Internet
Computer not working properly: Could the Motherboard be the problem |
||||