Re: [Xen-devel] AFS-based VBD backend

[Steve Traugott <stevegt@xxxxxxxxxxxxx>]

On Thu, Dec 23, 2004 at 10:42:18AM +0000, Keir Fraser wrote:
> > > Q:  Why not just use a loop device on top of AFS, with the 'file:' 
> > >     VBD type?
> > > A:  Loop devices on top of AFS files hang with large volumes of 
> > >     I/O -- looks like a deadlock of some sort (in my tests, a dd of
> > >     around 2-300 Mb into an AFS-based loop device appears to
> > >     consistently hang the kernel, even with a 500Mb or larger AFS
> > >     cache).  In addition, an unmodified loop.c will not fsync() the
> > >     underlying file; changes won't get written back to the AFS server
> > >     until loop teardown.  I've added an fsync() to the worker thread of
> > >     loop.c to take care of this every few seconds; that seems to work
> > >     but I can't really stress test it much because of the hang problem.
> > 
> > That it's already possible to use normal files. :)
> > 
> > So, no need for explicit support in xen. If your dom0 already knows and
> > uses afs, just specify the file in the xen configuration:
> > 
> > disk = [ 'file:/afs/file,sda1,w' ]
> 
> The OP did have an explanation why he didn't want to use a loop
> device. However, I would say that the correct approach here is
> probably to enhance/fix the existign loop support rather than adding a
> whole new backend driver.

I know that seems like the more modular approach, and I tried that
first, got as far as fixing the fsync() problem, ran into the hangs.
Those are consistent, but time-consuming to reproduce.  But even if we
clean them up we still would have an extra layer in between the block
backend and AFS, a layer that could be gotten rid of.  

I might be convinced to have another go at it; the question is, which is
more worth the development effort?  Xen's architecture is certainly a
lot cleaner, and might be easier to write a native file-based backend
for, than trying to troubleshoot and clean up the pile of spaghetti that
is the loop.c data flow.  I'm open to suggestions.

Steve
-- 
Stephen G. Traugott  (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@xxxxxxxxxxxxx 
http://www.stevegt.com -- http://Infrastructures.Org


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel