Xen project Mailing List

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

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@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

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