Xen project Mailing List

On Mon, Oct 21, 2013 at 8:57 PM, Christopher Greenhalgh <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]
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