On Sat, 2016-03-05 at 22:01 +0100, Christoph Hellwig wrote:
> > - if (atomic_read(&ibr->ib_bio_err_cnt))
> > - status = SAM_STAT_CHECK_CONDITION;
> > - else
> > + /*
> > + * Propigate use these two bio completion values from raw block
> > + * drivers to signal up BUSY and TASK_SET_FULL status to the
> > + * host side initiator. The latter for Linux/iSCSI initiators
> > + * means the Linux/SCSI LLD will begin to reduce it's internal
> > + * per session queue_depth.
> > + */
> > + if (atomic_read(&ibr->ib_bio_err_cnt)) {
> > + switch (ibr->ib_bio_retry) {
> > + case -EAGAIN:
> > + status = SAM_STAT_BUSY;
> > + break;
> > + case -ENOMEM:
> > + status = SAM_STAT_TASK_SET_FULL;
> > + break;
> > + default:
> > + status = SAM_STAT_CHECK_CONDITION;
> > + break;
> > + }
> > + } else {
> > status = SAM_STAT_GOOD;
> > + }
>
> I think you;d be much better off killing ib_bio_err_cnt and having
> an ib_error that gets set to the last / most server error.
That's what I was originally thinking too..
However, that means if one bio completed successfully and another got
-EAGAIN / -ENOMEM for the same se_cmd, IBLOCK would still complete
se_cmd with GOOD status.
I don't see how completing se_cmd with GOOD status, when one bio in the
set requested retry depending on completion order is a good idea.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
