On 11/30/2011 03:17 PM, Hannes Reinecke wrote:Virtio doesn't, but the underlying device/driver might.seg_max is the maximum number of segments that can be in aI would like to have the other request_queue limitations exposed
command. A bidirectional command can include seg_max input
segments and seg_max output segments.
here, too.
Most notably we're missing the maximum size of an individual segment
and the maximum size of the overall I/O request.
The virtio transport does not put any limit, as far as I know.
I was thinking of something along the lines of the TransportID as defined in SPC.As this is the host specification I really would like to see an host
identifier somewhere in there.
Otherwise we won't be able to reliably identify a virtio SCSI host.
I thought about it, but I couldn't figure out exactly how to use it. If
it's just allocating 64 bits in the configuration space (with the
stipulation that they could be zero), let's do it now. Otherwise a
controlq command is indeed better, and it can come later.
But even if it's just a 64-bit value, then: 1) where would you place it
in sysfs for userspace? I can make up a random name, but existing user
tools won't find it and that's against the design of virtio-scsi. 2) How
would it be encoded as a transport ID? Is it FC, or firewire, or SAS, or
what?
Yes, for a a shared (physical) SCSI host persistent reservations will be tricky.Plus you can't calculate the ITL nexus information, making
Persistent Reservations impossible.
They are not impossible, only some features such as SPEC_I_PT. If you
use NPIV or iSCSI in the host, then the persistent reservations will
already get the correct initiator port. If not, much more work is needed.