Re: [PATCH v4 3/3] block: improve detail in I/O error messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 18, 2011 at 4:13 AM, Hannes Reinecke <hare@xxxxxxx> wrote:
> Classify severity of I/O errors for target, nexus, and
> transport errors.
>
> Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>
> Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
> ---
>  block/blk-core.c |   23 ++++++++++++++++++++---
>  1 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 4ce953f..3380a49 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -2028,9 +2028,26 @@ bool blk_update_request(struct request *req, int error, unsigned int nr_bytes)
>
>        if (error && req->cmd_type == REQ_TYPE_FS &&
>            !(req->cmd_flags & REQ_QUIET)) {
> -               printk(KERN_ERR "end_request: I/O error, dev %s, sector %llu\n",
> -                               req->rq_disk ? req->rq_disk->disk_name : "?",
> -                               (unsigned long long)blk_rq_pos(req));
> +               char *error_type;
> +
> +               switch (error) {
> +               case -ENOLINK:
> +                       error_type = "recoverable transport";
> +                       break;
> +               case -EREMOTEIO:
> +                       error_type = "critical target";
> +                       break;
> +               case -EBADE:
> +                       error_type = "critical nexus";
> +                       break;
> +               case -EIO:
> +               default:
> +                       error_type = "I/O";
> +                       break;
> +               }
> +               printk(KERN_ERR "end_request: %s error, dev %s, sector %llu\n",
> +                      error_type, req->rq_disk ? req->rq_disk->disk_name : "?",
> +                      (unsigned long long)blk_rq_pos(req));
>        }
>
>        blk_account_io_completion(req, nr_bytes);
> --

Hi Jens,

Are you OK with this change provided James takes the SCSI patch?  If
so, should James pull this block patch in too to avoid dependency
concerns between trees?

Same question goes for the dm-mpath change (patch 2/3), Alasdair?

To ease merging with Linus, might be best if all patches were to go in
through a single tree.. if James were to carry these small block and
DM patches I'd wager chances of collision are slim.

Please advise, thanks.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux