* Matthew Dillon <[EMAIL PROTECTED]> [000525 13:58] wrote:
>
> :You, Matthew Dillon, were spotted writing this on Thu, May 25, 2000 at 10:57:33AM
>-0700:
> :>
> :> I don't particularly like to use MFS for 'large' partitions, mainly
> :> because cached data blocks wind up in core memory twice (once in MFS's
> :> memory map, and once in the VM page cache).
> :
> :You've said this several times in threads on MFS during recent months,
> :and I've always wanted to ask: is that a necessary 'feature' of MFS's
> :architecture, or something which could possibly be fixed without
> :too much hard work? For instance, would it be possible to force
> :VM not to cache MFS pages, etc.?
> :
> :--
> :Anatoly Vorobey,
>
> The double caching is a consequence of MFS's 'physical media' being
> the mmap() rather then real physical media. It would be difficult
> to fix, and probably not worth the effort.
>
> MFS's only advantage is that the double-caching tends to keep pages
> in-core longer, and you have less 'real' physical I/O because things
> like write-behind and buffer cache flushes are doing nothing more
> then flusing from the kernel's main VM page cache into MFS's memory
> map.
>
> If you have enough memory not to care about the double-caching issue,
> then MFS will work fine.
y'know...
We could do a really good job of a disk backed MFS by having a mount
flag for the syncer to ignore a mount point as well as marking it
async.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
