couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-1003) deleting db file is asynchronous & file rename in couch_file:delete
Date Sat, 01 Jan 2011 22:39:47 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976454#action_12976454
] 

Robert Newson commented on COUCHDB-1003:
----------------------------------------

deleting a large database can take time, especially on block-oriented filesystems (ext2/3/4,
for example).

The rename takes the same time regardless of size, the deletion happens asynchronously. On
startup, we check the .delete directory for any incomplete delete calls.

I think it's good behavior and we shouldn't change it. I also think we should revert the sleep
you added today to replication.js as we don't understand the real cause of the failure on
your machine (it passes here without the wait).


> deleting db file is asynchronous & file rename in couch_file:delete
> -------------------------------------------------------------------
>
>                 Key: COUCHDB-1003
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1003
>             Project: CouchDB
>          Issue Type: Question
>          Components: Database Core
>            Reporter: Benoit Chesneau
>
> I wonder why we spawn the file deletion when we delete a database. On slow io machine
it introduces latency. I don't see any reason we make this deletion asynchronous ?
> About couch_file:delete, we first rename the file before deleting it. Why are we doing
that ? Is this for windows ?

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


Mime
View raw message