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] 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! :-) 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
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.
|
