couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <>
Subject [jira] Commented: (COUCHDB-1003) deleting db file is asynchronous & file rename in couch_file:delete
Date Sat, 01 Jan 2011 23:05:48 GMT


Benoit Chesneau commented on COUCHDB-1003:

any link about it ? I wa expecting that filesystems already do this job.
same time compared to?

the deletion happens asynchronously. On startup, we check the .delete

I didn't ask for a change but reasons. I don't think it's good to not
check for deletion of a db file. It could introduce potential file
leaking I don't really like.

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).
the cause is latency in delete /rename on slow io. This isn't only on
my machine, btw but on every standard machines. I'm -1 reverting this
fix right now since it solved it on all machines tested here. Note:
this isn't the only test where we do apply such fix.

> deleting db file is asynchronous & file rename in couch_file:delete
> -------------------------------------------------------------------
>                 Key: COUCHDB-1003
>                 URL:
>             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.

View raw message