Date: Thu, 7 Jan 1999 21:59:29 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Terry Lambert <tlambert@primenet.com>, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <Pine.BSF.4.05.9901072142550.37756-100000@bright.fx.genx.net> In-Reply-To: <199901080219.SAA36593@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Jan 1999, Matthew Dillon wrote: > :... > :.. > :[snip] > : > :MFS is just lazyness, if you want it to grow/work right, you rewrite it > :instead of hacking FFS on top of it. > : > :or you design it in such a way that it's a device that FFS is somewhat > :aware of. this way when a block is asked to be filled what really happens > :is that the block passed in is put on the free block list and FFS is given > :a page of the MFS to use, when FFS pushes the block back to MFS the > :replaced page is put back under the vnode. > : > :MFS then becomes a device instead of a filesystem. > : > :although i think it violates some abstraction, does this make sense? > : > :-Alfred > > This actually does make some sense. What you are basically saying > is that it should be possible for the MFS device to rename a > VM page cached at a lower layer (mfsobj,page#) to a higher layer > (ffs_sub_object,page#). > > This isn't possible with the current VFS layering. That is, the > current VFS layering will pass a KVA mapped buffer down, but it > does not expect the lower layer to physically replace the pages > associated with the buffer with its own pages. Also, while the > clean/dirty state of the page could be retained, the relationship > with the lower layer's page's backing store would be lost when it > renames the page ( backing store works differently depend on the > type of object and cannot be transported across VFS layers ). The > page, clean, dirty, or TBD (to be destroyed) state would have to > eventually be passed back down to the lower layer when the upper layer > is done with it... an extremely dangerous proposition. um, this doesn't give us a growing MFS and i may be niave about this but consider: FFS requests a block passing in a buffer, the buffer is switched out from under the attached vnode and stored in the free list (or possibly the 'locked' list), a buffer from the Memory device is put in its place and the vnode is marked as such. FFS has the block for a while. Eventually the block is taken off the LRU list because of the nature of the LRU queue, anything removing a block must check the mark to see if it's MFS backed. In fact this could be a callback function, called in general when ANY buffers are reused allowing for other flexibilities, however, this callback may already be in place as the "flush to backing store" call that's done for traditional devices under FFS. At this point a buffer must be reattached to this vnode, it can be brought over from the free list, or perhaps the original buffer could have been placed on the 'locked' list (is this still around?) Maybe this is impossible with what we have, or doesn't make sense sorry. I _really_ need to UTSL more. :) -Alfred btw, what you and John Dyson are working on sounds trully awesome. I really hope you guys consider publishing a paper on it sometime because at that point FreeBSD will have moved so far from 4.4BSD, that the reference books become very far removed from the actual underlying system. 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.9901072142550.37756-100000>