[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MirageOS-devel] Irmin GC



I've been thinking about about GC in Irmin, and the effect it will
have on the API.

The basic problem we have at present is that adding things to the
internal stores (via the BC.Private APIs) only returns a hash. Nothing
prevents a garbage collection run from immediately removing the thing
you just added! These private interfaces are used by Ir_view and
Ir_sync, for example.

Proposal:

- Irmin should provide a smallish GC-safe core (BC?) that hides the
internal stores completely and provides an API that will not GC data
you're using. This API will distinguish between a "commit ID" (which
might or might not represent a commit in the repository) and a
"commit" (which refers to a commit in the repository and will prevent
it from being removed as long as you keep an OCaml reference to it).

- The core will need to provide named branches, commits and mutable
indexes/staging-areas that act as GC roots.

- Ir_view and Ir_sync should be implemented on top of this API, so
they don't have to worry about GC. Higher-level operations such as
merge should probably move to Ir_view too.

Issues:

- A "commit" should keep its contents (trees and blobs) from being
GC'd, but what about its parents? If we want to allow shallow clones,
we might need to allow for a commit's parents to be missing.

- GC with remote HTTP stores could be tricky. For custom protocols, GC
can be linked to the TCP connection, but HTTP is often spread over
multiple connections. Probably OK for the high-level API, but we might
have to remove the low one (I'm not very familiar with this REST API,
and so might be confused).

- If the user runs "git gc" manually on a Git-format store then all
bets are off, of course. Likewise if you have a store shared by
multiple processes.


Thoughts?


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.