Subject: Re: mfs woes
To: Paul Ripke <>
From: Chuck Silvers <>
List: tech-kern
Date: 07/17/2004 07:32:30
On Sat, Jul 17, 2004 at 06:04:05PM +1000, Paul Ripke wrote:
> On Saturday, Jul 17, 2004, at 12:40 Australia/Sydney, David Young wrote:
> >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.
> >>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?
> >
> >Discussion here and on ICB leads me to believe that md is a better bet
> >than mfs, but they will both waste memory by caching.
> Does anyone have plans to add something like the AIX/Linux O_DIRECT
> open(2)/fcntl(2) flag and/or the AIX "dio" mount option? I think
> this would have the desired effect. I'm getting a little fanatical
> about the dio mount option at work - it does have a noticeable impact.

adding support for O_DIRECT is on my list of things to do someday, yea.
that isn't what we'd want to use to fix the problems with MFS, though.
the better way to deal with MFS is to make it use swap-backed memory
directly instead of using FFS in a fake device that uses the address space
of a user process (mount_mfs) as its backing store.  this is a fair amount
of work, though.

btw, a brief look at mdconfig shows that it uses exactly the same cute hack
to provide backing memory for its devices, so it should behave identically
to mfs with respect to memory usage.  it would be fairly easy to change md
to have the kernel allocate swap-backed memory directly, which would save
the context switch currently required to access data in the user-process
backing-store, but that wouldn't help with the double-memory-usage issue.