[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Gabriel de Perthuis <g2p.code@xxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Wed, 14 Dec 2016 13:42:45 +0000
  • Cc: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 14 Dec 2016 13:42:53 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=URz1FFMWyHVNmYqbjlor++8jvNNtxmCTOZKJr+bKEsTGUV1nMX0 Qqizxq0pUWvlpD1rei7GqG77PU5gGYpmqCSjlEIVyY1j0a8Z/heKGhFD5goGnCd1 Ra+P/7B0eDRLhSb87rxCse+6bvY2Tc/gA0cVL1oxNfKFlxzgpv5ssVCM=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

On 14 Dec 2016, at 13:37, Gabriel de Perthuis <g2p.code@xxxxxxxxx> wrote:
> 
> Hello,

Dear Gabriel,

> I'm announcing I intend to work on the Mirage storage stack.
> 
> 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.
> 
> I'm envisioning a data layout that's suitable for SSDs, meaning it
> will be log-structured, fit large erase blocks and never rewrite
> in-place.  Unused blocks can be discarded in batches.

Welcome aboard, and glad to have you working on this very important
component!  When you are ready to share, it would be good to expand
on the scope of the initial version of the filesystem: for example how
many concurrent readers and writers are supported and so on.  The
first instance should be just fine with a single reader and writer, since our
primary usecase is to serialise an Irmin Git store to disk (and Irmin itself
will handle the concurrent writers and output a single stream of changes
to the filesystem).

Others on the list may comment about other use-cases they may have
as well for future iterations.

> 
> The target use case is applications that use Irmin, or applications
> written for a key-value API.
> Easy persistent storage will enable a large variety of applications
> that aren't feasible in Mirage currently.  For example, very
> short-lived micro-services that are spun on demand could still persist
> their internal state.
> 
> I hope this high-level design will work for the maximum number of
> users and make Mirage suitable for many more tasks.
> 
> The work is expected to take three months or so.
> 
> I'll be available on IRC during the bi-weekly call later today.
> Please raise any questions here by email or on IRC (#mirage on
> Freenode).  I'll try to also be available on the Slack channel for
> those who have access.

Looking forward to working with you on this!

regards,
Anil

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.