[
https://issues.apache.org/jira/browse/COUCHDB-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232964#comment-15232964
]
ASF GitHub Bot commented on COUCHDB-1003:
-----------------------------------------
Github user eiri commented on the pull request:
https://github.com/apache/couchdb-couch/pull/161#issuecomment-207611080
@rnewson @iilyak - the comments addressed.
Regarding rename-then-delete approach, just to move the comment here out of
the outdated diff:
As described here https://issues.apache.org/jira/browse/COUCHDB-1003 , this
is done because deletion of large files on block-oriented filesystems can take
time, so the file first moved into `.deleted` directory that got cleaned up on
couch start.
@rnewson if you think this is not applicable here, I'll remove the rename
part, I was just reproducing behaviour of `nuke_dir/2` as it was before this PR.
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
