Actually, I think I prefer; [mountpoints] /mnt/vol0 = foo, bar /mnt/vol1 = baz
with possible regexps or glob patterns on the right-hand side. B. On Thu, Jul 29, 2010 at 9:21 AM, Robert Newson <[email protected]> wrote: > 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 <[email protected]> > 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" <[email protected]> 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... >> >
