Re: [PATCH] tmpfs work update (was tmpfs initial work)

[Naoya Sugioka <naoya.sugioka@xxxxxxxxx>]

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
<dillon@apollo.backplane.com> 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
>
>