jeremy@classic.engr.sgi.com said:
> For example, in Fibrechannel using class 3 (the usual)
> send command (command frame corrupted; device does not receive)
> send barrier (completes normally)
> ... (lots of time goes by, many more commands are processed)
> timeout original command whose command frame was corrupted
This doesn't look right to me from the SCSI angle I don't see how you can get
a successful disconnect on a command the device doesn't receive (I take it
this is some type of Fibre magic?). Of course, if the device (or its proxy)
does receive the command then the ordered queue tag implementation requires
that the corrupted frame command be processed prior to the barrier, this
isn't optional if you obey the spec. Thus, assuming the processor does no
integrity checking of the command until it does processing (this should be a
big if), then we still must get notification of the failed command before the
barrier tag is begun. Obviously, from that notification we do then race to
eliminate the overtaking tags.
> There was also the problem of the queue full to the barrier command,
> etc.
The queue full problem still exists. I've used this argument against the
filesystem people many times at the various fora where it has been discussed.
The situation is that everyone agrees that it's a theoretical problem, but
no-one is convinced that it will actually occur in practice (I think it falls
into the "risk we're willing to take" category).
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:22 EST