> > > The other option for VSCSIIF_CMND_SCSI is a reset, but there is some
> > > debate as to whether a frontend using a single device on a physical
> > > scsi bus should be allowed to initiate a bus reset...
> > Yeah, an LU reset might be a better idea, if the underlying device can
> > handle it.
> It's a tricky situation, as there are some SCSI errors which do require
> a bus reset to resolve...
True.
> > Speaking of which, would it be a good idea to expose the tagged
> > command queueing stuff? I'd guess probably not, but I don't really
> > understand SCSI well enough to be sure.
> I think that that is implicitly exposed anyway, but my understanding of
> SCSI is probably about on par with yours, so I'm not absolutely sure.
Hmm. Looking at SAM 4 revision 10 section 5.1, things like the
I_T_L_Q nexus and task attributes are specified out-of-line relative
to the CDB, and I can't see any way of doing so in the current
protocol.
Tagged queueing would be nice to have, but its absence isn't really a
blocker for merging the patches, provided we have a plan for adding it
later if that proves necessary. Of course, if you add TCQ support you
probably also want the task management infrastructure, which is a
whole can of worms.
Actually, thinking some more, there may be some interesting issues in
the current protocol to do with INQUIRY and MODE SENSE commands.
They're currently being passed through to the physical device
essentially unchanged, so the frontend is going to claim to support
all the same features as the physical device. That probably means
we're claiming to be able to handle QUEUED task attributes, but then
ignoring them. That sounds like a really bad idea, because it means
we're basically dropping barriers, which will cause problems for
journaled filesystems. There are two obvious ways of fixing this:
1) Massage the inquiry and mode data from the frontend, or
2) Actually support all possible task metadata and commands.
Neither sounds particularly attractive. Hmm.
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home