All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jeff Garzik <jeff@garzik.org>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
	xen-devel@lists.xensource.com,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	Ian Pratt <ian.pratt@xensource.com>,
	linux-kernel@vger.kernel.org, Chris Wright <chrisw@sous-sol.org>,
	virtualization@lists.osdl.org
Subject: Re: [RFC PATCH 35/35] Add Xen virtual block device driver.
Date: Fri, 24 Mar 2006 15:55:27 +0000	[thread overview]
Message-ID: <1143215728.18986.15.camel@localhost.localdomain> (raw)
In-Reply-To: <4423E853.1040707@garzik.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jeff Garzik <jeff@garzik.org>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Chris Wright <chrisw@sous-sol.org>,
	virtualization@lists.osdl.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Ian Pratt <ian.pratt@xensource.com>,
	ian.pratt@cl.cam.ac.uk,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [RFC PATCH 35/35] Add Xen virtual block device driver.
Date: Fri, 24 Mar 2006 15:55:27 +0000	[thread overview]
Message-ID: <1143215728.18986.15.camel@localhost.localdomain> (raw)
In-Reply-To: <4423E853.1040707@garzik.org>

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


  parent reply	other threads:[~2006-03-24 15:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-22 16:52 [RFC PATCH 35/35] Add Xen virtual block device driver Ian Pratt
2006-03-22 16:52 ` Ian Pratt
2006-03-22 17:09 ` Anthony Liguori
2006-03-22 17:09   ` Anthony Liguori
2006-03-22 23:09 ` Jeff Garzik
2006-03-24 12:17   ` Alan Cox
2006-03-24 12:38     ` Jeff Garzik
2006-03-24 13:37       ` Jeff Garzik
2006-03-24 13:40         ` Arjan van de Ven
2006-03-24 13:50           ` Jeff Garzik
2006-03-24 15:33             ` Dave C Boutcher
2006-03-24 19:04               ` Mike Christie
2006-03-24 19:04                 ` Mike Christie
2006-03-24 19:19                 ` Dave C Boutcher
2006-03-25  0:32                   ` FUJITA Tomonori
2006-03-25  0:47                   ` Roland Dreier
2006-03-25  0:47                     ` Roland Dreier
2006-03-24 15:55       ` Alan Cox [this message]
2006-03-24 15:55         ` Alan Cox
2006-03-25 10:03         ` Rusty Russell
2006-03-25 10:03           ` Rusty Russell
2006-03-27 10:14   ` Peter Chubb
2006-03-23  8:19 ` Arjan van de Ven
2006-03-23  9:34   ` Keir Fraser
2006-03-23  9:34     ` Keir Fraser
2006-03-23  9:41     ` Arjan van de Ven
2006-03-23  9:42     ` Arjan van de Ven
  -- strict thread matches above, loose matches on Subject: below --
2006-05-09  8:49 [RFC PATCH 00/35] Xen i386 paravirtualization support Chris Wright
2006-05-09  7:00 ` [RFC PATCH 35/35] Add Xen virtual block device driver Chris Wright
2006-05-09 12:01   ` Christoph Hellwig
2006-03-22  6:30 [RFC PATCH 00/35] Xen i386 paravirtualization support Chris Wright
2006-03-22  6:31 ` [RFC PATCH 35/35] Add Xen virtual block device driver Chris Wright
2006-03-22 16:39   ` Anthony Liguori
2006-03-22 16:54     ` Christoph Hellwig
2006-03-27  8:42     ` Gerd Hoffmann
2006-03-27  8:42       ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1143215728.18986.15.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=chrisw@sous-sol.org \
    --cc=ian.pratt@xensource.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=virtualization@lists.osdl.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.