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-users

Re: [Xen-users] Re; TAP:AIO driver

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Re; TAP:AIO driver
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Mon, 28 Jan 2008 15:31:02 +0000
Cc: Gareth Bult <gareth@xxxxxxxxxxxxx>
Delivery-date: Mon, 28 Jan 2008 07:32:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <25703197.10741201392325096.JavaMail.root@zimbra>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <25703197.10741201392325096.JavaMail.root@zimbra>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)
> Is there any reason / instance where TAP:AIO might not work where FILE
> would work?

It was never a question of file flat-out not working; just that in some cases 
it performs badly in various ways and causes instability.

> For instance is TAP:AIO designed to work on network filesystems or local
> devices only?

Both.

> I've been told that FILE is bad, however, is this in the context of local
> devices, or also in the context of network filesystems ... ?

tap:aio is recommended generally, I believe.

On a local filesystem it has the advantage of not using up your loop devices.  
It may have better performance but I've not seen any numbers recently, so I'm 
not sure.  It may also have better memory use characteristics (see below).

The worst configuration I'm aware of for file: devices is on a network 
filesystem (NFS being the specific source of complaints but I imagine similar 
issues could arise for others).  Using the loop device (which is what file: 
does) on a file on an NFS filesystem is apparently a really good way to 
provoke OOM (out of memory) conditions in dom0's kernel, which will probably 
then start killing things randomly to free up memory.  Not good.

Using file-based VBDs on an NFS filesystem is a bit gross anyway and not 
something I'd recommend; but my understanding is that if you really want to 
do this, tap will be more stable.

(slightly confusingly, the same arguments probably don't all apply to HVM 
guests without the PV drivers installed, since I don't think file:/ in that 
case actually uses the loop device, although it probably does set it up)

tap also has the advantage of having some support for copy-on-write disk 
images using the qcow format, which might be something you want to look into 
if you have lots of domains based on a common base image.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

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

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