> > On 11/15/10 7:25 AM, Hannes Reinecke wrote: > > On 11/12/2010 09:40 PM, Zou, Yi wrote: > >> Hi, > >> I have noticed that in one of my testing where the target > >> supports REC but does not support RETRY in PRLI reply. > >> In this case, fc_fcp_srr() is never really sending SRR but > >> just goes to fc_fcp_retry_cmd() directly since > >> FC_RP_FLAGS_RETRY of the rport is not set. I understand > >> that no RETRY does not mean no REC from FCP-3 spec, > >> so we can't disable REC because of no RETRY, but for us, > >> in this case, we got REC accepted, but we are not > >> able to send SRR, does that mean we want to fail the I/O > >> at that point already? > > Currently we're using REC + SRR for error recovery (ie command > > retry). So from the implementation side it simply doesn't make any > > sense to send a REC and _then_ fail the I/O; we're not gaining any > > additional information here. > > Sending a REC would just enable us to detect if the exchange has > > completed, but we won't get any details of the transaction. > > > > So from my POV we could just short-circuit the logic here and _not_ > > send a REC if SRR is found not to be supported. > > > > Cheers, > > > > Hannes > > One way that REC might help is on very long transactions, like tape > motion (rewind, or a read issued after a long rewind). It lets > us extend the timeout on the read if the REC reports that it is > still working on it. However, I suppose it is unlikely that a tape > drive wouldn't support SRR, so maybe it's a moot point. I just > don't know enough about when REC might be supported without SRR. > > Cheers, > Joe
Thanks, Joe, I don't have much experience on tape, but the use case you mentioned here makes sense. I am not sure how often it is for REC w/o SRR for non tape device, or if it's the target problem. In any case, I believe the current behavior in libfc/fc_fcp is good enough. yi _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
