[tahoe-dev] got tahoe working on openbsd now

Brian Warner warner at lothar.com
Mon Nov 16 08:48:04 UTC 2009


kyle at arbyte.us wrote:
> Hi,
> 
> I'm happy to report that I've got tahoe working on OpenBSD now, connected
> to the test grid, and everything looks good.

Yay!

> I thought it was worth mentioning that when I run a tahoe command I do get
> some warnings about deprecated modules.  Are these well-known and nothing
> to worry about?

Yup. The next release of Twisted should probably fix the py2.6
deprecations therein; same for foolscap (the fix is already in trunk,
but I haven't made a new foolscap release yet). I think that Nevow might
have a couple still lingering.

> I think my approach will be to designate a few directories I want backed
> up, and do the backup operation perhaps every week or so.  I would want to
> keep a few historical copies of the data (e.g. one for last week, one for
> two weeks ago, up to a couple months of history).  Is there an automated
> way for me to do that as an incremental backup, or would I be making a
> complete copy every time?

The "tahoe backup" command is designed specifically for this. It does a
Time Machine-style timestamped snapshot, sharing files (and eventually
directories) between snapshots. If you only want to keep a few months
worth, just "tahoe rm" the older snapshots.

> Is there any kind of automatic deletion on the production servers?  I can
> easily delete the backups I no longer need, but I'm curious what happens
> when someone loses their references to backed up data.  Is that storage
> space lost permanently, unrecoverably, or is it somehow reclaimed?

There is no automatic garbage-collection, however somebody runs a manual
GC pass every once in a while (the last one took place in March). The
intention was to use a sort of mark-and-sweep scheme: we'd run a tool
that updates a "lease" on every reachable file, then once that's done we
ran a different tool that would delete shares that had no up-to-date
leases (actually this was the "lease expiration timer" that's built into
the tahoe storage server configuration).

Tahoe files become unrecoverable as soon as their filecap is lost, but
the server disk space is not reclaimed until GC causes the shares to be
deleted.

cheers,
 -Brian



More information about the tahoe-dev mailing list