Re: [RFC] training mpath to discern between SCSI errors
From: Mike Christie <hidden>
Date: 2010-08-25 19:14:28
Also in:
dm-devel, linux-fsdevel, linux-ide, linux-scsi, lkml
On 08/25/2010 10:59 AM, Mike Snitzer wrote:
On Wed, Aug 25 2010 at 4:00am -0400, Kiyoshi Ueda[off-list ref] wrote:quoted
quoted
I'm not sure how to proceed here. How much work would discerning between transport and IO errors take? If it can't be done quickly enough the retry logic can be kept around to keep the old behavior but that already was a broken behavior, so... :-(I'm not sure how long will it take.We first need to understand what direction we want to go with this. We currently have 2 options. But any other ideas are obviously welcome. 1) Mike Christie has a patchset that introduce more specific target/transport/host error codes. Mike shared these pointers but he'd have to put the work in to refresh them: http://marc.info/?l=linux-scsi&m=112487427230642&w=2 http://marc.info/?l=linux-scsi&m=112487427306501&w=2 http://marc.info/?l=linux-scsi&m=112487431524436&w=2 http://marc.info/?l=linux-scsi&m=112487431524350&w=2 errno.h new EXYZ http://marc.info/?l=linux-kernel&m=107715299008231&w=2 add block layer blkdev.h error values http://marc.info/?l=linux-kernel&m=107961883915068&w=2 add block layer blkdev.h error values (v2 convert more drivers) http://marc.info/?l=linux-scsi&m=112487427230642&w=2 I think that patchset's appoach is fairly disruptive just to be able to train upper layers to differentiate (e.g. mpath). But in the end maybe that change takes the code in a more desirable direction?
I think it is more disruptive, but is the cleaner approach in the end. #2 looks hacky. In upper layers, we will have checks for dasd and other AOE and other drivers. And then #2 does not even work for filesystems (ext said they need this).
2) Another option is Hannes' approach of having DM consume req->errors and SCSI sense more directly.