| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [RFC PATCH 35/35] Add Xen virtual block device driver.
|
To: |
Jeff Garzik <jeff@xxxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [RFC PATCH 35/35] Add Xen virtual block device driver. |
|
From: |
Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> |
|
Date: |
Fri, 24 Mar 2006 15:55:27 +0000 |
|
Cc: |
Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, SCSI Mailing List <linux-scsi@xxxxxxxxxxxxxxx>, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx |
|
Delivery-date: |
Fri, 24 Mar 2006 15:50:10 +0000 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4423E853.1040707@xxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<A95E2296287EAD4EB592B5DEEFCE0E9D4B9E8A@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4421D943.1090804@xxxxxxxxxx> <1143202673.18986.5.camel@xxxxxxxxxxxxxxxxxxxxx> <4423E853.1040707@xxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Gwe, 2006-03-24 at 07:38 -0500, Jeff Garzik wrote:
> > A pure SCSI abstraction doesn't allow for shared head scheduling which
> > you will need to scale Xen sanely on typical PC boxes.
>
> Not true at all. If you can do it with a block device, you can do it
> with a SCSI block device.
I don't believe this is true. The complexity of expressing sequences of
command ordering between virtual machines acting in a co-operative but
secure manner isn't as far as I can see expressable sanely in SCSI TCQ
>
> In fact, SCSI should make a few things easier, because the notion of
> host+bus topology is already present, and notion of messaging is already
> present, so you don't have to recreate that in a Xen block device
> infrastructure.
Those are the easy bits.
> > are also always full of bits people got wrong, often critical bits like
> > tagged queues and error sequences - things that break your journalled
> > file system.
>
> This I'll grant you.
And every one you get wrong is a corruptor....
Alan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home