Hi Hannes, Thank you for working on this issue and sorry for very late reply... (08/30/10 23:52), Hannes Reinecke wrote: > From: Hannes Reinecke <hare@xxxxxxx> > Date: Mon, 30 Aug 2010 16:21:10 +0200 > Subject: [RFC][PATCH] scsi: Detailed I/O errors > > Instead of just passing 'EIO' for any I/O errors we should be > notifying the upper layers with some more details about the cause > of this error. > This patch updates the possible I/O errors to: > > - ENOLINK: Link failure between host and target > - EIO: Retryable I/O error > - EREMOTEIO: Non-retryable I/O error > > 'Retryable' in this context means that an I/O error _might_ be > restricted to the I_T_L nexus (vulgo: path), so retrying on another > nexus / path might succeed. Does 'retryable' of EIO mean retryable in multipath layer? If so, what is the difference between EIO and ENOLINK? I've heard of a case where just retrying within path-group is preferred to (relatively costly) switching group. So, if EIO (or other error code) can be used to indicate such type of errors, it's nice. Also (although this might be a bit off topic from your patch), can we expand such a distinction to what should be logged? Currently, it's difficult to distinguish important SCSI/block errors and less important ones in kernel log. For example, when I get a link failure on sda, kernel prints something like below, regardless of whether the I/O is recovered by multipathing or not: end_request: I/O error, dev sda, sector XXXXX Setting REQ_QUIET in dm-multipath could mask the message but also other important ones in SCSI. Thanks, -- Jun'ichi Nomura, NEC Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
