CA-27472: Add slightly more debug info to the request failure path.

Replace the hardcoded EIO we dump to the logs. We do have an actual
error to display. The interesting piece is actually vreq->error, response
status is rather boring.

Doing it like this should also prevent people from attributing
failures to *real* EIO, as would be the case with NFS or physical
device issues.

Not that vreq->error may be zero on some failure paths. Consider this
useful information as well; these case can be attribute path to
tapdisk-vbd itself, meaning the respective treqs may have never made
it down to the block driver.

diff --git a/drivers/tapdisk-vbd.c b/drivers/tapdisk-vbd.c
index 3c68f4158266062d87d4316c38c6ac6fb4f79296..9d49559e398ea6dab27d4ee787b4e65afc23cd67 100644 (file)
--- a/drivers/tapdisk-vbd.c
+++ b/drivers/tapdisk-vbd.c
@@ -1181,7 +1181,7 @@ tapdisk_vbd_make_response(td_vbd_t *vbd, td_vbd_request_t *vreq)
            (int)tmp.id, tmp.sector_number, vreq->status);
 
        if (rsp->status != BLKIF_RSP_OKAY)
-               ERR(EIO, "returning BLKIF_RSP %d", rsp->status);
+               ERR(-vreq->error, "returning BLKIF_RSP %d", rsp->status);
 
        vbd->returned++;
        vbd->callback(vbd->argument, rsp);