couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Windows support
Date Mon, 15 Jun 2009 01:22:31 GMT

On Jun 14, 2009, at 6:45 PM, Mark Hammond wrote:

> On 15/06/2009 7:49 AM, Damien Katz wrote:
>>
>> On Jun 10, 2009, at 7:56 PM, Mark Hammond wrote:
>>
>>> On 4/06/2009 3:27 AM, Damien Katz wrote:
>>>> I was once again reminded we need to add proper Windows support for
>>>> CouchDB when Mark Hammond provided a very nice patch to provide a
>>>> windows version of a couchdb unix script. (Thanks Mark!)
>>>
>>> Thanks! Sorry I was a bit slow to see this thread.
>>>
>>>> But we also have some broken tests. Other than the issue Mark's  
>>>> patch
>>>> fixes, I think it's only compaction that's still broken.
>>>
>>> compaction and deletion are broken. I've opened a bug on the delete
>>> problem at https://issues.apache.org/jira/browse/COUCHDB-326, as
>>> alisdair seemed to think that couch could have a simple change  
>>> made to
>>> allow 'delete' to work without changing how the files are opened.
>>>
>>> > I think the
>>>> cleanest way to fix that is to change the erlang VM to open db  
>>>> files
>>>> using flags to give them unix like semantics.
>>>
>>> I've learnt something about Windows file-systems today :) My
>>> experiments show that when using FILE_SHARE_DELETE:
>>>
>>> * A file can be deleted while it is in use - but another file of  
>>> that
>>> name can not be created until the handles are closed.
>>>
>>> * A file can however be renamed while it is in use, thereby allowing
>>> the original name to be re-opened.
>>>
>>> If we consider the 'delete' case, then FILE_SHARE_DELETE may still  
>>> end
>>> up with a 'race' if an attempt to delete the DB is quickly  
>>> followed by
>>> a request to create it - the delete should succeed, but the create
>>> will not.
>>>
>>> If we consider the 'compact' case, I *suspect* that couch will  
>>> need to
>>> rely on the ability to rename and replace rather than a simple  
>>> delete
>>> - so that might work fine.
>>>
>>> I'll have a bit of a dig around in the erlang sources and see what I
>>> find, but of you have any other thoughts or pointers in the  
>>> meantime,
>>> please let me know.
>>>
>>> Cheers,
>>>
>>> Mark
>>
>>
>>
>> Perhaps all files that get deleted (via explicit deletion or due to
>> compaction) should first be renamed or moved to special trash dir  
>> just
>> before being actually deleted. The file should be given a random  
>> name to
>> avoid conflicting with previous deletions.
>
> I don't see how this will fix things for delete without also  
> changing the open mode of the file - if the file is still opened by  
> one of the couchdb processes, the rename to a temp file will still  
> fail.  If we change couch such that the couch process is terminated  
> before deleting there should be no need to also change the file  
> mode, nor to use a temp dir.  If we do change the file mode, there  
> should be no need to use a temp dir either.
>
> IOW, using a temp dir doesn't change the fact that either (a) all  
> handles must be closed before rename/delete or (b) we change the  
> open mode of the file.  Unless of course I'm missing something.
>
> Is it possible that for the delete case we can do as suggested in  
> COUCHDB-326 - ie, after we signal the couchdb processes to  
> terminate, actually wait for termination to complete?
>
> I understand compaction may be trickier still when it comes to  
> swapping the original and compacted files over, but the same basic  
> invariants apply - either we investigate changing the mode of the  
> file, or we take steps to ensure the relevant couch processes have  
> terminated at that time.
>
> My apologies if I'm missing something obvious,



Sorry, I wasn't clear, but I'm assuming we'll need to change the  
erlang vm to use the proper flags.

What I meant was I'll get the Erlang side of ready, someone needs to  
patch and build the Windows Erlang vm and test if it works. Then we'll  
merge the Erlang portion of the code to trunk and see about getting  
the patch upstream to erlang vm, and in the meantime those who want to  
build on windows will need to patch Erlang themselves.

-Damien



Mime
View raw message