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: [Xen-devel] AFS-based VBD backend

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] AFS-based VBD backend
From: Steve Traugott <stevegt@xxxxxxxxxxxxx>
Date: Thu, 23 Dec 2004 03:58:45 -0800
Cc: Luciano Miguel Ferreira Rocha <strange@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 23 Dec 2004 12:00:39 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1ChQQE-0002jk-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <20041223103717.GA21603@xxxxxxxxxxxxx> <E1ChQQE-0002jk-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
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