On 26/02/2010 4:18 PM, Juhani Ränkimies wrote:
The branch is an experiment, trying to find a solution for the
compaction and db-delete problems on windows
Ack - I should have guessed - sorry about that :)
There is one patch specific to the windows build process; for the case
when path to inno setup contains spaces.
http://github.com/juranki/couchdb/commit/0d5ec88f08a0519fdf9521730361c6da0c3d4cb4
I've incorporated that one.
Regarding the file versioning - I'm sorry that we haven't kept you in
the loop a little better, but with Damien's guidance we think we have
found a better strategy for this.
The root of this strategy comes from a realization that if a file is
opened on windows with FILE_SHARE_DELETE, the file can be deleted *or
renamed* while it is open. One limitation is that a file of the same
name can not be re-created while the old one still has handles open (the
'deleted but still open' file still appears in directory listings until
the handle is closed, for example)
Given this, what we can do is something like:
* Arrange for erlang to be able to open the DB and view files with this
flag.
* Instead of deleting a file before replacing it, we first rename the
file to a unique name (ie, based on a UUID) in a special directory.
* As couch starts up, attempt to delete any old files in this special
directory. In theory, no such files should exist - the OS should take
care of actually removing any such files even if erlang crashes.
The end result of this is that things can be made to work with a lot
less friction than the 'file versioning' scheme. I've a patch to
couchdb that works when used with a patch to erlang to open *all* files
with that flag. The next step down this path seems to be to create an
erlang 'port driver' for disk IO and use this instead of the builtin
erlang file objects. We've identified a 'bfile' erlang port driver we
may be able to fork and adapt to our needs - using our own port driver
would also allow optimizations to the file IO for non-windows platforms
(eg, indicate to the OS that certain files should not get OS-level
caching, etc)
Unfortunately, none of this has been discussed anywhere formal - much of
it was on IRC - so I apologize if this is the first you heard of it.
But whatever strategy we wind up with for this is almost certainly not
going to land and be tested enough to make 0.11.
Cheers,
Mark
