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 <[email protected]> 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 <[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 _______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
