[jira] Closed: (COUCHDB-767) do a non-blocking file:sync

["Adam Kocoloski (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COUCHDB-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Kocoloski closed COUCHDB-767.
----------------------------------

    Resolution: Fixed

Randall, after your realization that the fsync could be initiated by the db_updater process this patch got a _lot_ simpler.  We don't need couch_file:rename or any of that stuff.  Anyone who wants to do an fsync in a separate process simply needs to know the filename in order to do it.

> do a non-blocking file:sync
> ---------------------------
>
>                 Key: COUCHDB-767
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-767
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>    Affects Versions: 0.11
>            Reporter: Adam Kocoloski
>             Fix For: 1.1
>
>         Attachments: 767-async-fsync.patch, async_fsync.patch, async_fsync_v3.patch
>
>
> I've been taking a close look at couch_file performance in our production systems.  One of things I've noticed is that reads are occasionally blocked for a long time by a slow call to file:sync.  I think this is unnecessary.  I think we could do something like
> handle_call(sync, From, #file{name=Name}=File) ->
>     spawn_link(fun() -> sync_file(Name, From) end),
>     {noreply, File};
> and then
> sync_file(Name, From) ->
>     {ok, Fd} = file:open(Name, [read, raw]),
>     gen_server:reply(From, file:sync(Fd)),
>     file:close(Fd).
> Does anyone see a downside to this?  Individual clients of couch_file still see exactly the same behavior as before, only readers are not blocked by syncs initiated in the db_updater process.  When data needs to be flushed file:sync is _much_ slower than spawning a local process and opening the file again --  in the neighborhood of 1000x slower even on Linux with its less-than-durable use of vanilla fsync.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.