couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
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;

[databases]
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
cluster).

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

B.


On Thu, Jul 29, 2010 at 3:21 AM, Randall Leeds <randall.leeds@gmail.com> 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" <damien@apache.org> 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...
>

Mime
View raw message