Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Irmin: Git-like distributed, branchable storage

openmirage.org

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Irmin: Git-like distributed, branchable storage

#21

Post by avsm »

sitkack wrote: post #18
djs55 wrote: post #5

Earlier quoted context omitted.

I'm refactoring "Xenstore" (part of the control-plane for a Xen host) to use it. I want to make the server stateless so I can restart it if it crashes.. this mainly involves remembering lots of bits of state: connection information, watch registration, pending events etc. I also want to make it easier to debug while I'm at it. I've got a draft of a blog post here: https://github.com/djs55/mirage-www/blob/a1ab2fec78fa…

I know it won't help, but I was thinking that one could keep hot backups by doing a fork() suspend() and then diffing the heap in realtime to migrate state between processes. Trying to keep state on the heap instead of the stack is a huge start. But this is stuff you already know.

Using process checkpointing is indeed one good way to implement fault tolerance. The Irmin style is more explicit -- the heap itself is tree structured, and the application uses it to checkpoint itself to disk/memory as a matter of course.

This ensures that only the minimal state required is stored (as opposed to the entire process heap), and also that state can be reconstructed intelligently to preserve sharing and special resources. For instance, file descriptors (if running in Unix mode) could be reified to a filename/offset and reopened, and memory mapped areas (such as the shared ring structures that Xen uses) could be re-granted from the hypervisor.

Re: Irmin: Git-like distributed, branchable storage

#22

Post by ivotron »

avsm wrote: post #20
hyp0 wrote: post #19

I don't quite understand the use-case, because merging seems problematic if purely programmatic... A merge that seems clean might violate some invariants of the object. And if irmin detects that it can't automatically merge, how is the merge done programmatically? Perhaps the idea is more like a database, and some administration is manual. So, merges are like mini-migrations. Or, merges could be thrown back to a huma…

The idea is that you can tailor the merge functions for the application problem domain, rather than grabbing an off-the-shelf distributed database with subtly different consistency semantics than the one you really need (e.g. Riak, Dynamo and Cassandra are all slightly different in how they reconcile, for very good reasons). With Irmin, if your your application needs a distributed queue to coordinate workflow tasks,…

this is very similar to how Bayou reconciles conflicts

http://research.microsoft.com/apps/pubs/default.aspx?id=7377...

BTW, would be much appreciated if you could point to related work on the subject (papers, other projects, blogs, etc).

Re: Irmin: Git-like distributed, branchable storage

#23

Post by avsm »

ivotron wrote: post #22
avsm wrote: post #20

Earlier quoted context omitted.

The idea is that you can tailor the merge functions for the application problem domain, rather than grabbing an off-the-shelf distributed database with subtly different consistency semantics than the one you really need (e.g. Riak, Dynamo and Cassandra are all slightly different in how they reconcile, for very good reasons). With Irmin, if your your application needs a distributed queue to coordinate workflow tasks,…

this is very similar to how Bayou reconciles conflicts http://research.microsoft.com/apps/pubs/default.aspx?id=7377... BTW, would be much appreciated if you could point to related work on the subject (papers, other projects, blogs, etc).

That's correct, except that an Irmin client could choose not to reconcile if it would conflict, and just continue on with two active branches (presumably hoping for a future event that would help reconciliation). Bayou's a big inspiration for this system -- there's a filesystem under development that exposes some POSIX semantics using Irmin as a base. It should be possible to build rather interesting datastructures that go beyond conventional filesystems as well, though.

BTW, would be much appreciated if you could point to related work on the subject (papers, other projects, blogs, etc).

That'll certainly happen when we complete the research papers on the subject. It's a little out of scope for a blog post series that primarily focuses on trying to explain the stuff we're building.

Re: Irmin: Git-like distributed, branchable storage

#24

Post by sitkack »

avsm wrote: post #21
sitkack wrote: post #18

Earlier quoted context omitted.

I know it won't help, but I was thinking that one could keep hot backups by doing a fork() suspend() and then diffing the heap in realtime to migrate state between processes. Trying to keep state on the heap instead of the stack is a huge start. But this is stuff you already know.

Using process checkpointing is indeed one good way to implement fault tolerance. The Irmin style is more explicit -- the heap itself is tree structured, and the application uses it to checkpoint itself to disk/memory as a matter of course. This ensures that only the minimal state required is stored (as opposed to the entire process heap), and also that state can be reconstructed intelligently to preserve sharing and…

It would be interesting to have an operating system that used a queue of transactions for IO, esp against an immutable FS somewhat like Datomic.

Re: Irmin: Git-like distributed, branchable storage

#26

Post by CMCDragonkai »

avsm wrote: post #20
hyp0 wrote: post #19

I don't quite understand the use-case, because merging seems problematic if purely programmatic... A merge that seems clean might violate some invariants of the object. And if irmin detects that it can't automatically merge, how is the merge done programmatically? Perhaps the idea is more like a database, and some administration is manual. So, merges are like mini-migrations. Or, merges could be thrown back to a huma…

The idea is that you can tailor the merge functions for the application problem domain, rather than grabbing an off-the-shelf distributed database with subtly different consistency semantics than the one you really need (e.g. Riak, Dynamo and Cassandra are all slightly different in how they reconcile, for very good reasons). With Irmin, if your your application needs a distributed queue to coordinate workflow tasks,…

Can irmin be used a block device filesystem? Or would it only support object based storage?
Post reply on HN