WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1

> The blkfront driver should request id+offset+length from the blkback
> driver. The blkback driver then converts the id into either a device, or a
> file. Seems rather straight forward to me.

OK, it's not a very cunning hack to do but it makes the blkback driver more 
complex whilst duplicating functionality that's already in the kernel.  You'd 
have to deal with a load of VFS APIs as well as the existing block APIs, 
which would be unfortunate.

Does anybody know why the existing loopback device performs badly anyway?  As 
Adam says, it shouldn't be rocket science to make it work well...

> > From what I've heard the loop driver itself could use a bit of work to
> > make it really useful: it comes at a performance / memory usage hit :-(. 
> > We recommend using LVM for any really serious environments for this
> > reason.
> >
> > An alternative architecture would be to have a userspace daemon for file
> > backed VBDs, using the blktap framework (unstable tree only).  I'm not
> > sure if this would work any better than the current way of doing files,
> > tho...
>
> blktap?  Is that similiar to what I described above?

Blktap allows you to write a userspace program to provide a block device to 
another domain.  It makes what you described a bit more straightforward than 
implementing directly in the blkback driver.

Cheers,
Mark

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

<Prev in Thread] Current Thread [Next in Thread>