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

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

...and just to throw a third into the mix in case of interest (though
not very complete, and not currently maintained as far as I know), I
had a project student (Rupert Horlick) do some work last year on a
Path ORAM block store implementation using Mirage, the evaluation of
which entailed building a small FS implementation. His code is at

https://github.com/ruhatch/mirage-btrees
https://github.com/ruhatch/mirage-block-fs
https://github.com/ruhatch/mirage-oram

On 29 December 2016 at 18:14, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

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