Hi, On Wed, Mar 12, 2003 at 07:19:16PM -0500, Joey Hess wrote: > Emile van Bergen wrote: > > > Then you are probably second-guessing the kernel's disk caching, and > > > should be using /tmp or something instead. > > > > The difference between /tmp and a mode 1777 directory in /mem is that > > the capacity/speed tradeoff may be different for each. > > With a large emphasis on the "may". /mem may be in swap, and the kernel > may decide to keep everything you write to /tmp in cache. So indeed they > may have inverted properties to what you might assume. > > I have never seen a program in all of Debian that legitimatly needs a > ram disk for faster file operations. I've never even run upon one that > claims it needs such a thing. I think your /mem is a solution in search > of a problem. /mem/tmp alone would be, yes. But the combination of /mem, /mem built from a skeleton at bootup, /mem/run, /mem/preserved that may be copied back and *possibly* a mode 1777 /mem/tmp, is a solution for: - the ifstate and/or dhcp vs. networked var problem - things that must be cleaned at boot - less important differences between tmpfs, shmfs, ramfs and ext2-on-ramdisk - readonly / or /etc - laptop disk spinups - applications that think they're smarter than the kernel in deciding how long their files should live and whether it should ever go through block allocation on a disk-based fs. (Whether they're right in that should indeed be judged on a per-application basis). None of these things on their own may be important enough to implement a /mem for, but taken together I think it's worth it, especially because it's a relatively elegant and generic solution for these problems, and because it's easy to implement. I'm implementing it in three scripts right now. The first one is an /etc/init.d/mountmem, intended to be linked to from /etc/rcS.d/S09mountmem (just before checkroot), that mounts /mem either as tmpfs, shmfs, ramfs or ext2 on /dev/ram0 or /dev/ram1, depending on what's available, or not at all; SLASHMEMTYPE in /etc/default/rcS can be used to specify the types to be tried in any desired order. The second is /etc/init.d/initmem, that empties and inits /mem -- whatever it is, wherever it is -- from a skeleton at startup, and is intended to be linked to from /etc/rcS.d/S36initmem.sh. The third is /etc/init.d/savemem, that saves /mem/preserved back to its corresponding directory in the skeleton, and is intended to be linked to from /etc/rcS.d/S301savemem, between S30urandom and S31umountnfs.sh. When I'm done, I'll put it on a webpage, so everyone can have a look for himself. I'll stop trying to convince you all now; as I implement the solutions using /mem for the problems above I'll let you know how it works out. EOT, for now. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpKunAcfxYjz.pgp
Description: PGP signature