On Fri, 1 May 2009 05:43:50 am Christoph Hellwig wrote:
> On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> > How exactly does it introduce additional latency? A scsi command block is
> > hardly large or complicated. Are you suggesting that a 16/32byte scsi
> > command takes significant
On Fri, May 01, 2009 at 12:08:06PM +0100, Jamie Lokier wrote:
> If you're using virtio-block to connect to lots of LUNs on lots of
> targets (i.e. lots of block devices), don't you need similar queuing
> code and error handling for all that too?
Currenly there's a 1:1 relation of virtio drivers an
Christoph Hellwig wrote:
> On Thu, Apr 30, 2009 at 10:49:19PM +0100, Paul Brook wrote:
> > Only if you emulate a crufty old parallel scsi bus, and that's just silly.
> > One of the nice things about scsi is it separates the command set from the
> > transport layer. cf. USB mass-storage, SAS, SBP2(
On Thu, Apr 30, 2009 at 10:49:19PM +0100, Paul Brook wrote:
> Only if you emulate a crufty old parallel scsi bus, and that's just silly.
> One of the nice things about scsi is it separates the command set from the
> transport layer. cf. USB mass-storage, SAS, SBP2(firewire), and probably
> severa
On Thu, Apr 30, 2009 at 4:49 PM, Paul Brook wrote:
> One of the nice things about scsi is it separates the command set from the
> transport layer. cf. USB mass-storage, SAS, SBP2(firewire), and probably
> several others I've forgotten.
ATAPI, SCSIoFC, SCSIoIB
--
Javier
--
To unsubscribe fr
On Thursday 30 April 2009, Christoph Hellwig wrote:
> On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> > How exactly does it introduce additional latency? A scsi command block is
> > hardly large or complicated. Are you suggesting that a 16/32byte scsi
> > command takes significantly l
On Thu, 2009-04-30 at 22:13 +0200, Christoph Hellwig wrote:
> On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> > How exactly does it introduce additional latency? A scsi command block is
> > hardly large or complicated. Are you suggesting that a 16/32byte scsi
> > command
> > takes
On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> How exactly does it introduce additional latency? A scsi command block is
> hardly large or complicated. Are you suggesting that a 16/32byte scsi command
> takes significantly longer to process than a 16byte virtio command
> descripto
On Wednesday 29 April 2009, Christoph Hellwig wrote:
> On Wed, Apr 29, 2009 at 12:11:19PM +0100, Paul Brook wrote:
> > Is this actually measurably faster, or just infinitesimally faster in
> > theory?
>
> On normal disks it's rather theoretical. On high-end SSDs and arrays the
> impact is noticeab
On Wednesday 29 April 2009, Christian Borntraeger wrote:
> Am Wednesday 29 April 2009 13:11:19 schrieb Paul Brook:
> > On Wednesday 29 April 2009, Christoph Hellwig wrote:
> > > On Tue, Apr 28, 2009 at 11:37:01AM -0500, Anthony Liguori wrote:
> > > > Ah, excellent. I think that's a great thing to
On Wed, Apr 29, 2009 at 12:11:19PM +0100, Paul Brook wrote:
> Is this actually measurably faster, or just infinitesimally faster in theory?
On normal disks it's rather theoretical. On high-end SSDs and arrays the
impact is noticeable, mostly due to the additional latency.
--
To unsubscribe from
Am Wednesday 29 April 2009 13:11:19 schrieb Paul Brook:
> On Wednesday 29 April 2009, Christoph Hellwig wrote:
> > On Tue, Apr 28, 2009 at 11:37:01AM -0500, Anthony Liguori wrote:
> > > Ah, excellent. I think that's a great thing to do. So do you think
> > > virtio-scsi would deprecate virtio-blk
On Wednesday 29 April 2009, Christoph Hellwig wrote:
> On Tue, Apr 28, 2009 at 11:37:01AM -0500, Anthony Liguori wrote:
> > Ah, excellent. I think that's a great thing to do. So do you think
> > virtio-scsi would deprecate virtio-blk?
>
> I don't think so. If you have an image format or a non-sc
Am Wednesday 29 April 2009 12:50:04 schrieb Christoph Hellwig:
> On Tue, Apr 28, 2009 at 09:09:52PM +0200, Christian Borntraeger wrote:
> > Yes, virtio-scsi is also something we were thinking of. The last time we
> > discussed this idea of SCSI passthrough internally, we stumbled over error
> > r
On Tue, Apr 28, 2009 at 11:37:01AM -0500, Anthony Liguori wrote:
> Ah, excellent. I think that's a great thing to do. So do you think
> virtio-scsi would deprecate virtio-blk?
I don't think so. If you have an image format or a non-scsi blockdevice
underneath virtio-block avoids the encoding in
On Tue, Apr 28, 2009 at 09:09:52PM +0200, Christian Borntraeger wrote:
> Yes, virtio-scsi is also something we were thinking of. The last time we
> discussed this idea of SCSI passthrough internally, we stumbled over error
> recovery. Who is responsible for the error recovery? The host, the guest
Am Tuesday 28 April 2009 11:51:54 schrieb Christoph Hellwig:
> Not quite yet. Eventually I want to support a virtio-scsi kind of
> transport which would use the same virtio-blk protocol but only send
> scsi commands. We'd need a different driver on the Linux side for
> it that registers to the sc
Am Tuesday 28 April 2009 18:37:01 schrieb Anthony Liguori:
> Christoph Hellwig wrote:
> >> Should we be
> >> handling some SCSI cmds internally to QEMU (like eject operations) and
> >> supporting media=cdrom in -drive for if=virtio?
> >>
> >
> > Not quite yet. Eventually I want to support a
Christoph Hellwig wrote:
Should we be
handling some SCSI cmds internally to QEMU (like eject operations) and
supporting media=cdrom in -drive for if=virtio?
Not quite yet. Eventually I want to support a virtio-scsi kind of
transport which would use the same virtio-blk protocol but only s
On Mon, Apr 27, 2009 at 09:36:51AM -0500, Anthony Liguori wrote:
> So practically speaking, what can you do with this?
It's interesting if your underlying device is a real scsi disk and you
want virtio for efficiency but also allow to issue scsi commands on
the underlying device, e.g. for finding
20 matches
Mail list logo
