On Wed, 2004-03-17 at 22:23, Scully, William P wrote: > The following technique seems to work for us, with SLES8. > > - In /etc/fstab: > > /dev/dasdb1 /tmp ext2 defaults 0 0 > > - In boot.local: > > # Create and mount the disk space used for /tmp > mke2fs /dev/dasdb1 > mount /dev/dasdb1 /tmp > chmod o=t /tmp > chmod a+rwx /tmp
So apparently you can get away with /tmp come in that late (or maybe things are writing on your root device until your mount the device). But this does not mean it is always wise to do. I don't know enough about Linux to tell whether it is important to have high bandwidth to /tmp. My systems seem to have the ssh-* subdirectories with the sockets to my ssh-agent forwarding (these live in inode cache anyway afaik) and some stuff that YaST left there, and I think also rpm builds go there. You would need to define the VDISK for peak requirements in /tmp. If Linux is continuously writing things into /tmp and deleting them, over time you will touch all pages in your VDISK and make it very unpleasant for CP to back that up with paging space. I even think an EW DCSS may not be the best thing to do (for the same reasons) because pages are copied back and forth between DCSS and Linux main memory you are wasting z/VM real memory. Let me phrase it differently: when you use VDISK for swap then some process data is active either in main memory or on VDISK, but not both. When you hold real data in VDISK, much of it will be active both on VIDSK and in page cache. This doubles your memory requirements for it. How about using ramfs for it? Is that going to hurt you? mount -t ramfs ramfs /tmp I believe that ramfs could even be swapped by Linux (to VDISK), but thinking about that makes my head hurt... Rob ---------------------------------------------------------------------- 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
