Bob Beck wrote:
> I really dislike "CHEAP".
>
> and it almost seems like these should actually be NOCACHE.. why the heck
> can't they be?
So i looked at NOCACHE, but it seemed like that option may destroy the buffer
too soon. Anyway, I tested it and it does go boom. With just NOCACHE in mfs,
> Isn't the solution to this problem a working dynamic buffer cache? I'm
> not sure adding a hack for mfs, and the complexity that comes with it,
> is the way to go. Did somebody analyzed what broke when the buffer
> cache was cranked to 90%?
My digging suggested that something on "write side"
I really dislike "CHEAP".
and it almost seems like these should actually be NOCACHE.. why the heck
can't they be?
On Thu, Sep 8, 2016 at 7:49 PM, Ted Unangst wrote:
> Currently, the bufcache doesn't know that mfs is backed by memory. All i/o
> to
> mfs ends up being
On 08/09/16(Thu) 14:49, Ted Unangst wrote:
> Currently, the bufcache doesn't know that mfs is backed by memory. All i/o to
> mfs ends up being double cached, once in the userland process and again in the
> kernel bufcache. This is wasteful. In particular, it means one can't use mfs
> to increase
Currently, the bufcache doesn't know that mfs is backed by memory. All i/o to
mfs ends up being double cached, once in the userland process and again in the
kernel bufcache. This is wasteful. In particular, it means one can't use mfs
to increase the effective size of the buffer cache. Reading or