couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1342) Asynchronous file writes
Date Fri, 18 Nov 2011 06:31:52 GMT


Paul Joseph Davis commented on COUCHDB-1342:


For #3 the issue is that it's broken. Granted there's lots in CouchDB that breaks Erlang idioms,
but this is basic broken window theory. We *know* this is broken and its easily fixable. Why
would we check in something that we know is broken?

For #4 the patch is reimplementing parts of the standard library. In Erlang there's a Right
Way™ to start a process synchronously that might fail to initialize. It reduces the code
that we have to write and maintain and its considerably more tested than the custom implementation
we have here. Trying to minimize this by calling it a "style issue" is not conducive to the
technical discourse.

You're also forgetting #2 which you agreed can be done. And if done it not only reduces the
size of this patch in terms of total lines, but reduces the number of files that are touched,
as well as removes the need for people to scour the source for places that we might need to
add calls to couch_file:flush/1 and also prevents the need for devs to remember to add it
in the future. And it also makes the flushing more optimal in terms of decreased message passing

I'm sorry, but the culture issue here is that you continue to be subtly derogatory by deriding
technical comments as a "pet concerns". This is especially disheartening when I've spent so
much time and effort on trying to help by reviewing this patch and responding to this conversation.
The sad part is that most of the things I've voiced an opinion on are easy to fix or abstract
enough that a brief discussion on the issue with a list of things to watch out for would have
been enough to assuage my concerns.

This patch is less than 48 hours old and it changes a core aspect of how we write data to
disk in a database that prides itself on not losing data. What are you honestly expecting
for a time table here? It hasn't been two days and you've already referenced speed of development
and project progress multiple times in response to technical points.

You ask for my help yet you remain dismissive of anything I'm offering. I'm sorry you're frustrated
but this is how code review works. I just recently finished maintaing a 7K line refactor for
over a month while people reviewed it and even made changes to code that I was refactoring
which I had to then merge (behavior, not code) into my branch. I understand how painful review
can be, but that's how this system works and I, for one, thinks it makes us stronger.
> Asynchronous file writes
> ------------------------
>                 Key: COUCHDB-1342
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>            Reporter: Jan Lehnardt
>             Fix For: 1.3
>         Attachments: COUCHDB-1342.patch
> This change updates the file module so that it can do
> asynchronous writes. Basically it replies immediately
> to process asking to write something to the file, with
> the position where the chunks will be written to the
> file, while a dedicated child process keeps collecting
> chunks and write them to the file (and batching them
> when possible). After issuing a series of write request
> to the file module, the caller can call its 'flush'
> function which will block the caller until all the
> chunks it requested to write are effectively written
> to the file.
> This maximizes the IO subsystem, as for example, while
> the updater is traversing and modifying the btrees and
> doing CPU bound tasks, the writes are happening in
> parallel.
> Originally described at
> Github Commit:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message