Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support. (RFC)

[Julian Chesterfield <jac90@xxxxxxxxxxxx>]

> On 19/6/06 10:56 pm, "Anthony Liguori" <aliguori@xxxxxxxxxx> wrote:
>
> > Julian Chesterfield wrote:
> > > > On 19/6/06 8:15 pm, "Anthony Liguori" <aliguori@xxxxxxxxxx> wrote:
> > > >
> > > > > Couple general comments on the code:
> > > > >
> > > > > Please don't introduce more (ab)uses of /proc.  Sure it's just for
> > > > > debugging but there's no reason to not make that sysfs.
> > > > >
> > > > > I'm not an expert here, but the nopage handlers that I've seen 
> > > > > return
> > > > > NOPAGE_SIGBUS instead of manually causing a SIGBUS on current.
> > > > >
> > > > > I think it's better to use C99 initialization than GCC:
> > > > >
> > > > >   owner:  ...,  =>  .owner = ...,
> > > > >
> > > > > Some of the indenting is a bit off from Linux CodingStyle.  Stuff 
> > > > > like
> > > > > if( => if ( and some random spaces after an (.
> > > > >
> > > > > There's some code commented out with C++ comments too.
> > > > >
> > > > > What's the significance of /**BLKTAP**/ and /**TAPEND**/?
> > > > >
> > > > > I'm a little surprised to see these conversion tools too.  
> > > > > Wouldn't it
> > > > > be easier to just add some parameters to qemu-img?
> > > Thanks for the comments anthony. When we initially played with qcow
> > > images it was easier to knock-up our own frontend to the plugins for
> > > converting between the different image types and testing features 
> > > like
> > > image sparseness.  We added an optimisation feature in the xen qcow
> > > plugin which would allocate full extents for non backing file based
> > > images as well as the asynchronous callback architecture to enable
> > > request batching for AIO.
> > >
> > > We could certainly adapt qemu-img to use these and other features. 
> > > Not
> > > sure what the best approach for keeping the toolsets in synch between
> > > the 2 projects would be though.
> > It may be worth just bringing up the changes on qemu-devel.  I know 
> > why
> > you'd want to change the cluster size (it's a pain to work with 
> > clusters
> > < block size).  I saw another comment about making metadata more
> > coarse.  Can you clarify the reasons for that?
We've been thinking about an enhancement to the qcow driver to use 
smarter readahead on the request ring in order to speculatively limit 
the number of metadata writes where request batching is used. This is 
an advantage of having access to the full frontend request queue which 
enables the userspace agent to make smart decisions regarding caching 
and safe but minimal metadata writes.
(Not sure which comment you'd read, but hope this may answer it!)

- Julian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel