couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: exdev regression on trunk when using multiple mount points
Date Thu, 29 Jul 2010 08:21:14 GMT
I'd rather go the other way and allow some kind of globbing or regexp
in the .ini file to find the databases. It was always a bit of a hack
to embed the volume name into the database.

I'm thinking something like;

foo* = /mnt/vol0
bar* = /mnt/vol1
baz* = /mnt/vol2

that way you can move databases between volumes without renaming them
(or have replicas of databases on differently named volumes around a

There would be a single, top-level .delete directory per unique volume.


On Thu, Jul 29, 2010 at 3:21 AM, Randall Leeds <> wrote:
> This maybe gets into the realm of over-engineering, but we could track the
> deleted files elsewhere so we don't have to find them.
> One solution is a _trash db. Insert, rename file, delete async and clear the
> document if it succeeds. Consume changes and delete the files on startup.
> Advantages: deleting only one file at a time, never losing track, no
> scanning. Disadvantage: if we crash between deleting the file and deleting
> the document we can't tell later if a mount is unavailable or the file is
> already gone, so we risk leaving garbage files around or garbage in our
> _trash and someone might hack our gibson.
> Sent from my interstellar unicorn.
> On Jul 28, 2010 6:46 PM, "Damien Katz" <> wrote:
> I worry about installations with many many databases (like Canonical
> UbuntuOne with over a million). Walking the dir structure to look for
> .delete files would take a very long time. Though I suppose it could scan it
> async and not block server operation.
> -Damien
> On Jul 28, 2010, at 5:56 PM, Randall Leeds wrote:
>> Hmmm. Would it be crazy to walk the tree nuki...

View raw message