Hi Matt, Thank you for the precise response. It is a same strategy of previous porter. I thought it is a way to remove a dirty hack (vm object and anonymous object shares rb_memq) I'll play around implementing a buffer cache (or maybe, a page cache)...it is a most interesting part of this poring.
Regarding to the old APIs, I try to migrate the code to follow your vm change first. thank you again, -Naoya On Tue, Jan 19, 2010 at 8:34 AM, Matthew Dillon <[email protected]> wrote: > :Hello Matt and df users again, > : > : > :Here is an update of my tmpfs porting. The filesystem is getting much > :more robust than initial post, > :but still I see same memory corruption issue. > : > :Yet I feel it is a worth to share this update with community to catch > :up recent vm_pager_getpage() / vm_pager_has_page() changes. > : > :Any feedback and comments are welcome. > : > :thank you, > :-Naoya > > The patch is looking better. > > The first issue I see is tmpfs_read()/tmpfs_write() and friends. > You need to use the buffer cache to implement those VOPs instead > of trying to mess with the VM pages directly. Interacting with > VM pages in a way that avoids problems between read, write, and mmap, > is a very complex task. The buffer cache takes the work out of it. > > The second issue is trying to create a duplicate VM object with the > same rb_memq. Instead it should be possible to use the same > VM object and simply give it an extra reference so it isn't destroyed > when the vnode goes away. > > For the latter we will also need a way to deal with dirty VM pages > when the VM system wants to 'flush' them to backing store (since there > is no backing store). The way this normally works is that the VM > system clears the dirty bits on the VM pages when it marks the > buffer cache buffer as being dirty, and calls the strategy function > (that would be tmpfs_strategy() if you had one) on the buffer > cache buffer to 'flush' the buffer to backing store. Since there is > no media per-say I think it might be possible to implement a strategy > function which simply re-dirties the underlying VM pages for writes. > (Eventually we could add a swap-space-backing feature, even!). > > As you know I am doing some major work on the VM/BUF APIs. I think > you can do most of the above without that work interfering too much. > I've decided to keep the old API (vtruncbuf() and vnode_pager_setsize()) > intact while I work on a new, better API. > > -Matt > >
