Re: [MirageOS-devel] [ANNOUNCE] Mirage storage project

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Just to update the list, Tom and Gabriel had an off-list discussion about the 
differences of their approaches and came to the conclusion that two approaches 
are indeed warranted.  Tom's effort is focussed on verification and uses 
b-trees, whereas Gabriel's design is more performance-optimised and uses 
hitchhiker trees.

I anticipate seeing more convergence of these after the first iterations of 
both are released.  Linux has a zillion filesystems, so Mirage now goes from 
zero to two :-)

regards,
Anil

> On 17 Dec 2016, at 12:16, Tom Ridge <tom.j.ridge@xxxxxxxxxxxxxx> wrote:
> 
> I'm also working in this area!
> 
> At the moment I have a working B-tree implementation (with delete!) and I 
> hope to interface this to ocaml-9p, to provide a remote "persistent map" (KV 
> store) which could be mounted in Linux. Of course, it could also be used 
> directly on the mirage block layer without much further work. Performance is 
> looking very good, primarily because of various optimizations to the B-tree 
> (bulk-insert, caching, delayed write till sync etc).
> 
> So I am not sure that it is worth starting another project.
> 
> Ultimately I want to provide a POSIX filesystem interface, via sibylfs.
> 
> Thanks
> 
> T
> 
> 
> 
> On 14 December 2016 at 17:13, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 14 Dec 2016, at 17:09, Gabriel de Perthuis <g2p.code@xxxxxxxxx> wrote:
> >
> > Le 14/12/2016 à 17:23, Sean Grove a écrit :
> >>    I'm announcing I intend to work on the Mirage storage stack.
> >>
> >> Very cool!
> >>
> >>
> >>    There is a clear need for something that sits on top of the BLOCK API
> >>    and provides higher-level capabilities.  I'm planning to write a
> >>    storage library that provides a key-value store (with fixed-size keys)
> >>    and an Irmin backend.  A more generic key-value store with variable
> >>    size keys could also be implemented on top.
> >>
> >>
> >> A lot of my use cases are probably in the minority for Mirage, but will
> >> you design/implement it with an eye towards the JavaScript runtime
> >> (either via jsoo of BuckleScript)? The dream for me has always been to
> >> sync data between web/mobile clients and a Mirage server, like Cuekeeper.
> >
> > I think CueKeeper should be able to take advantage of a new Irmin
> > backend pretty easily.  Both ends of the connection are using Irmin, the
> > browser uses an IndexedDB backend, and the server could start using this
> > new disk-backed Irmin backend.
> >
> > The key-value API will include details about handling disk barriers,
> > garbage collection, possibly other things that are not relevant to the
> > browser.  That API won't aim to be easily reimplemented in a browser.
> > But Irmin can be, so that shouldn't be an issue.
> 
> I believe that Thomas Gazagnaire has been working on a revision of
> the Irmin API that distills down the interface to a simpler version for
> the common path.  We've been using Irmin pretty heavily in Docker for Mac,
> so the lessons learnt from that use should hopefully translate into a more
> lightweight developer experience for the Irmin v2 API.
> 
> regards,
> Anil
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


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