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 <[email protected]> wrote: > On 14 Dec 2016, at 17:09, Gabriel de Perthuis <[email protected]> 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 > [email protected] > https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
