Date: Wed, 7 Jun 2000 09:13:42 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Valentin Nechayev <netch@lucky.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <200006071613.JAA01082@apollo.backplane.com> References: <200006070424.e574Od303232@cwsys.cwsent.com> <200006070655.XAA97086@apollo.backplane.com> <20000607144421.A82711@lucky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Of course, of course.
:It is general problem of any public-accessable resource.
:Do you think you can really fix this world? Or do you try to emit /tmp
:as philosophical category?
:
:> MFS is a terrible idea for /tmp. Each page in an MFS filesystem eats
:> *TWO* pages of physical memory (until swapped). This means that the
:
:It is problem of one broken realization, isn't it?
:
:--
:NVA
No, I think its a problem with concept. Modern systems like ours
have a VM page cache which can cache anything -- including normal
filesystems. Normal filesystems aren't quite as fast as MFS (even
with an async mount) because we assume, rightly, that certain pieces
of data can be flushed more quickly in order to leave more memory
available to other things. The concept of 'MFS' in general could be
rephrased to be 'forcing the system to use more memory to cache
a filesytem at the cost of making less memory available to programs
and other filesystems'.
If a person wants that tradeoff, then it would be just as easy to
implement with a normal filesystem simply by turning off the update
daemon (for that filesystem), turning off write-behind (for that
filesystem), and either increasing the size of the buffer cache to
accomodate more dirty pages or disassociating the dirty filesystem
pages from the buffer cache (making them look like dirty mmap'd pages).
And then using an async mount.
A memory filesystem, even the best implemented one you could write,
is best used in situations where you don't *have* a local disk
in the first place.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006071613.JAA01082>