DragonFly BSD
DragonFly users List (threaded) for 2010-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 19 Jan 2010 08:34:33 -0800 (PST)

: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




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]