In message <20040714033948.GB13570@che.ojctech.com>, David Young writes:
>On Tue, Jul 13, 2004 at 11:17:20PM -0400, Steven M. Bellovin wrote:
>> In message <20040713230112.A426@noc.untraceable.net>, Andrew Brown writes:
>> >On Tue, Jul 13, 2004 at 05:18:31PM -0500, David Young wrote:
>> >>I am told that blocks in the memory filesystem (mfs) can end up in the
>> >>buffer cache: this double-whammy on memory can lead to memory exhaustion.
>> >
>> >yes, 'cause it's a "file system".
>> >
>> >>The problem is compounded (I do not understand how or why) when multiple
>> >>mfs are in use.
>> >>
>> >>Is there any bug-fix or work-around for the memory-inefficiency/exhaustion
>> >>issue?  Can somebody outline what a fix would look like?
>> >
>> >write a real swap-based file system?  mfs also comes with a ~2.9
>> >gigabyte limit (on i386, at least).  when using USE_TOPDOWN_VM.  when
>> >you're not, it comes with a ~1.8 gigabyte limit.  regardless of how
>> >much ram or swap you have.
>> 
>> Given the new buffer cache architecture, I've been wondering if mfs 
>> even makes sense these days.  Perhaps a disk partition mounted with 
>> async would provide comparable performance?  I don't know; I haven't 
>> tried it.  But I'm getting ready to bring up a new machine; I might 
>> reserve a partition and see what happens.
>
>I think that an in-memory filesystem makes the most sense for my
>applicatoin: I am using either a CompactFlash card or a CD-ROM as the
>"hard drive."  I do not want to keep volatile information on the former;
>I cannot keep it on the latter.
>
You and Andrew make good points about special cases.  I should amend my 
suggestion: does MFS make sense for /tmp on ordinary machines?

		--Steve Bellovin, http://www.research.att.com/~smb