> Hi James-san,
>
> On Thu, 21 Feb 2008 14:39:47 +1100
> "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:
> > Just responding to myself, would I be guessing correctly that you
> > removed the timeout field to make the request structure smaller? The
top
>
> That is one reason. However, the main reason is as follows.
>
> The time that guests/host will get is not real world's time on
> virtualized environment. The time depends on hypervisor's scheduling.
> (Is this assumption right ?)
>
>
> For example, if upper layer of the pvSCSI frontend specified 5 seconds
> as timeout, it should be treated as real world's time or within a
guest
> domain's world time ?
>
> We didn't have clear answer when we implemented that part. Therefore,
> we coded it temporally 5 seconds.
>
> James-san, how do you think about this issue ?
I don't think the exact value of the timeout matters that much. At
worst, a 5 second timeout is going to be at least 5 seconds, and
probably not much more than that. It's the Linux SCSI subsystem itself
that handles the timeout anyway.
> By the way, we understand that the 5 seconds is too short to support
> tape device.
Yes, way too short. For running the HP LT&T (Library and Tape Tools),
even 60 seconds is too short for some operations.
FYI, I have the HP LT&T working nicely under windows now. All tests
succeed, even a firmware update to the tape drive worked. A Read/Write
test on a HP LTO2 drive with LTO1 media gives me 13.3MB/s (approx
800MB/minute) for both read and write operations. I assume that a CD or
DVD burner would work also, although I don't have one to test.
Are you planning on requesting that pvSCSI get merged into the Xen tree
once you have the timeout and unload issues sorted out?
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home