Re: [RFC] block: fix barrier error transmission

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Apr 02 2008, James Bottomley wrote:
> There's a problem with barriers in SCSI.  They're prepared as a
> SYNCHRONIZE_CACHE REQ_TYPE_BLOCK_PC command.  However, our processing
> model dictates that we always return no block error but set req->errors
> to the SCSI result.  The upshot is that if we get an error on a flush
> barrier, it's never seen by the block layer.
> 
> This patch attempts to get the block layer to see such errors.  Note,
> it's still not quite right.  There are possible sense errors that could
> indicate success of the command (like deferred errors) that this will
> treat as failures.  I suppose we could process the sense in scsi and try
> to return a first pass error even for REQ_TYPE_BLOCK_PC ... I'm just not
> sure what that will do to the other users.
> 
> James
> 
> ---
> 
> diff --git a/block/blk-barrier.c b/block/blk-barrier.c
> index 55c5f1f..3a3947c 100644
> --- a/block/blk-barrier.c
> +++ b/block/blk-barrier.c
> @@ -114,18 +114,24 @@ void blk_ordered_complete_seq(struct request_queue *q, unsigned seq, int error)
>  
>  static void pre_flush_end_io(struct request *rq, int error)
>  {
> +	error = rq->errors ? -EIO : error;
> +
>  	elv_completed_request(rq->q, rq);
>  	blk_ordered_complete_seq(rq->q, QUEUE_ORDSEQ_PREFLUSH, error);
>  }

It's a bit of a hack, SCSI really should pass the error value back
instead of fiddling around with possibly perhaps finding it in ->errors.
And please don't use these ?: constructs, in this case it doesn't even
make a lot of sense and a

        if (rq->errors)
                error = -EIO;

would have been much cleaner ;-)

So my question is why does the model not allow you to return the error
properly?

-- 
Jens Axboe