Date: Fri, 8 Jan 1999 01:52:09 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: (mfs idea) Re: questions/problems with vm_fault() in Stable Message-ID: <Pine.BSF.4.05.9901080123210.37756-100000@bright.fx.genx.net> In-Reply-To: <199901080608.WAA37994@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Jan 1999, Matthew Dillon wrote: > :The buffer is just marked as dirty so that the FFS doesn't overwrite it. > :MFS _must_ reclaim them into it's own address space to avoid being > :overwritten. > : > :Since i assume that when a buffer is flushed it should then be free > :you have to 'give something back' > :... > > I think I understand. The problem is that the system has no clue that > the vm_page needs to be returned to MFS. Once MFS gives the page away, > that is the end of the matter as far as the system is concerned. When a block device fills in a buffer and it is then written to causing it to become dirty, doesn't it have to be flushed to the same device it was fetched from? Since MFS is a pseudo device _and_ a filesystem, won't all dirty pages actually be handed back eventually to the device portion of the code? Doing a lookup can determine if the buffer is actually part of the newfs process, or just a formulated write... (this would be a memory to memory copy, or MFS could steal this buffer and traverse the LRU to force out a buffer to return.) You are saying that the dirty buffer can be lost to the MFS, if this is possible, then how do the other filesystems maintain stability if they can possibly never be flushed out? > Now, of course, we could *make* the system aware that it needs to do > something special with the page -- but if we do not create a generally > useful mechanism it would be nothing more then a bad hack. Any mechanism > that we would create to handle this situation would have to handle > moving the page across an arbitrary number of VFS layers, and then either > handed back down through the same layers or handed back to the original > layer... we cannot assume it will be moved across only two VFS layers. since MFS is a bottom layer, the pages can be moved around as much as you want, with the stipulation that since it's dirty it always must be sent back to be flushed out... which is where the swap is of actual address space for buffer pages is done... i think it's more of a hack in the MFS than the general filesystem code, all that has to be done is that the buffers (which are really just pages of the mfs allocation) are always marked dirty so they make their way back to the storage (the address space of the mfs entity) > Essentially, the vm_alias mechanism that I described would be able to > handle this sort of situation. Could we hack in something simpler? > Probably, but it might not be generic enough to be useable in other > situations. A _real_ MFS is always good, one that has a maximum size, and doesn't need to satisfy the FFS's optimizations for mass storage and does zero copy. I was just wondering if it's possible to do this as a temporary improvement? I really need to understand and read the code more, consider me off your back for the time being. :) thanks, -Alfred > > -Matt > > > Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet > Communications & God knows what else. > <dillon@backplane.com> (Please include original email in any response) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901080123210.37756-100000>