Re: [MirageOS-devel] mutable store on mirage?

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

I've taken a look at Baardskeerder, and it looks extremely good for a Xen
port indeed (and possibly as an Irminsule backend for the blob store,
Thomas).

Issue: https://github.com/mirage/mirage/issues/185

I'd suggest using it more for logging and the like, but the only hitch is
that it doesn't compile under non-Linux yet due to depending on some
non-Posix ioctls, but that should be fairly easy to patch with a portable
but less durable equivalent.

-anil

On Fri, Nov 01, 2013 at 10:50:59AM +0000, Christopher Greenhalgh wrote:
> As I said in the call, I've got baardskeerder running in Xen/mirage over 
> blkif.
> https://github.com/cgreenhalgh/baardskeerder/
> https://github.com/cgreenhalgh/baardskeerder/blob/master/xen_test/README.md
> I've run the bsmgr benchmark(s) to run on it, but my dev set-up is in a 
> virtual box vm and I was using xen blktap for the vdisk
> https://github.com/cgreenhalgh/baardskeerder/blob/master/benchmark-out.txt
> I added page cacheing to the baardskeerder store over blkif but performance 
> is still ~10 slower then direct lwt on unix, and my xen setup is currently 
> about twice as slow again (hopefully down to the blktap disk - I couldn't get 
> xen-disk to compile and I haven't got lvm set up at the mo).
> 
> Anyway, I'll leave the performance alone for now and try building a web app 
> with it and cohttp/etc
> 
> Cheers
> Chris
> 
> 
> 
> From: cl-mirage-bounces@xxxxxxxxxxxxxxx 
> [mailto:cl-mirage-bounces@xxxxxxxxxxxxxxx] On Behalf Of Christopher Greenhalgh
> Sent: 23 October 2013 16:42
> To: David Scott
> Cc: Mirage List
> Subject: RE: mutable store on mirage?
> 
> I don't feel like I know enough about block device internals to suggest an 
> alternative yet.
> 
> I've now made a first-cut port of baardskeerder to mirage (splitting out 
> mirage & unix dependencies into sub-packages):
> https://github.com/cgreenhalgh/baardskeerder
> This has a store that runs over blkif, but currently only the basic 
> baardskeerder Flog0 log option (which has little resilience and no 
> compaction). The store also does no cacheing at the moment...  (needs mirage 
> 0.9.8, i.e. io_page fix)
> 
> I've make a very simple mirage btree fa?ade over this:
> https://github.com/cgreenhalgh/ocaml-btree
> This is passing basic tests on unix, but I haven't got a test harness 
> together yet to try it on Xen.
> 
> The Opam packages are in:
> https://github.com/cgreenhalgh/opam-dev-repository
> unix-simple-blkdev
> mirage-baardskeerder
> ocaml-btree
> 
> cheers
> Chris
> 
> 
> From: 
> cl-mirage-bounces@xxxxxxxxxxxxxxx<mailto:cl-mirage-bounces@xxxxxxxxxxxxxxx> 
> [mailto:cl-mirage-bounces@xxxxxxxxxxxxxxx] On Behalf Of David Scott
> Sent: 21 October 2013 21:16
> To: Christopher Greenhalgh
> Cc: Mirage List
> Subject: Re: mutable store on mirage?
> 
> Hi Chris,
> 
> Thanks for taking a look at this. When I get a moment I'll check out your 
> code and see if it makes sense to merge in some patches I've got lying around.
> 
> The Blkif API is very quirky. I think we should chuck it away and put 
> something sensible in place. Feel free to propose a new signature! :-)
> 
> Cheers,
> Dave
> 
> On Mon, Oct 21, 2013 at 8:57 PM, Christopher Greenhalgh 
> <Chris.Greenhalgh@xxxxxxxxxxxxxxxx<mailto:Chris.Greenhalgh@xxxxxxxxxxxxxxxx>> 
> wrote:
> Partly as a learning exercise I have made a blkif implementation over a 
> single file using Lwt_unix - 
> https://github.com/cgreenhalgh/mirage-unix-simple-blkif
> It has a couple of basic tests which it passes, but hasn't been exercised 
> beyond that yet;
> Neither is it abstracted over threading, but then the Blkif interface isn't 
> yet either...
> i intend to try using it as a baardskeerder store next, so we'll see what 
> happens.
> 
> Threw up a few questions...
> 
> As noted in the comment near the top of 
> https://github.com/cgreenhalgh/mirage-unix-simple-blkif/blob/master/lib/blkdev.ml
>  i don't think it will behave precisely the same as ocaml-xen-block-driver 
> for concurrent multi-block reads and writes: currently it will do each in one 
> chunk while the xen driver subdivides and potentially interleaves large reads 
> and...
> 
> Btw there seems to be an ambiguity in the OS.Devices.Blkif interface, 
> specifically what should happen if write_page is called with an Io_page which 
> is actually >1 page long (e.g.from Io_page.get N)? ocaml-xen-block-driver 
> write_page seems to assume that it will be exactly one page (without 
> checking) but is the intended bevaviour (a) split pages and handle each page 
> in turn or (b) explicit error?
> 
> It is also slightly unclear (to me) what the ordering semantics are intended 
> to be for read_512; currently this and the xen-block-driver only actually 
> initiate the read when a thread attempts a (blocking) get on the returned 
> Lwt_sequence. This is the more obvious route as read_512 is non-blocking 
> (i.e. has to immediately return the sequence), but feels slightly odd.
> 
> p.s. as there is no sync operation, is there a particular level of sync to 
> disk/durability defined in the xen block protocol?
> 
> I'm also unsure if it is deliberate that Io_page.page_size isn't visible; i 
> had to use Io_page.round_to_page_size 1 to get page_size out...
> 
> cheers
> chris
> 
> 
> _________________________
> From: Richard Mortier 
> [Richard.Mortier@xxxxxxxxxxxxxxxx<mailto:Richard.Mortier@xxxxxxxxxxxxxxxx>]
> Sent: 16 October 2013 21:16
> To: David Scott
> Cc: Christopher Greenhalgh; Mirage List
> Subject: Re: mutable store on mirage?
> 
> On 16 Oct 2013, at 21:08, David Scott wrote:
> 
> > I'd like to see unix blkif implemented (without using the xen 
> > implementation). I've got some patches lying around which open files with 
> > O_DIRECT and perform unbuffered sector-aligned I/O. I was thinking of 
> > making a 'unix-block-driver' with this code in it, mirroring the xen 
> > implementation. It's mostly a thin veneer over Lwt_bytes, replacing 
> > Bigarray.t with Cstruct.t. In future I was thinking the mirage-platform 
> > repo could become the minimal 'boot' code plus module types for Blkif, 
> > Netif etc; and all the concrete implementations could be spun out into 
> > other repos.
> >
> > What do people think?
> 
> absolutely agree. thought perhaps we would want to functorise(*) over Lwt, eg 
> packages named
> 
> mirage-blk-xen-lwt
> mirage-blk-posix-async
> mirage-blk-bsd-blah
> 
> etc...?  opam can handle the constraints though (i firmly expect :)
> 
> (*) if i'm making up a verb there and/or using it incorrectly, i apologise... 
> :)
> 
> 
> --
> Cheers,
> 
> R.
> 
> 
> 
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system, 
> you are advised to perform your own checks. Email communications with the 
> University of Nottingham may be monitored as permitted by UK legislation.
> 
> 
> 
> 
> 
> 
> --
> Dave Scott
> 
> 
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment 
> may still contain software viruses which could damage your computer system, 
> you are advised to perform your own checks. Email communications with the 
> University of Nottingham may be monitored as permitted by UK legislation.
> 
> 
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> 
> 
> This message has been checked for viruses but the contents of an attachment
> 
> may still contain software viruses which could damage your computer system, 
> you are advised to perform your own checks. Email communications with the 
> University of Nottingham may be monitored as permitted by UK legislation.
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Anil Madhavapeddy                                 http://anil.recoil.org

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