couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hammond <skippy.hamm...@gmail.com>
Subject Re: Windows 0.11 snapshot
Date Fri, 26 Feb 2010 23:00:17 GMT
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

Mime
View raw message