aboutsummaryrefslogtreecommitdiffstats
path: root/block
diff options
context:
space:
mode:
authorYi Zou <yi.zou@intel.com>2012-08-30 19:26:25 -0400
committerJens Axboe <axboe@kernel.dk>2012-08-30 19:26:25 -0400
commit37d7b34f05b7bcca364bdf47d8955e766094a244 (patch)
treeab1ae9d7b1f92212f7b19f819683c4d6a510d71c /block
parent155e36d40cf31c17f2b629fc2f2f5527e4cfc324 (diff)
block: rate-limit the error message from failing commands
When performing a cable pull test w/ active stress I/O using fio over a dual port Intel 82599 FCoE CNA, w/ 256LUNs on one port and about 32LUNs on the other, it is observed that the system becomes not usable due to scsi-ml being busy printing the error messages for all the failing commands. I don't believe this problem is specific to FCoE and these commands are anyway failing due to link being down (DID_NO_CONNECT), just rate-limit the messages here to solve this issue. v2->v1: use __ratelimit() as Tomas Henzl mentioned as the proper way for rate-limit per function. However, in this case, the failed i/o gets to blk_end_request_err() and then blk_update_request(), which also has to be rate-limited, as added in the v2 of this patch. v3-v2: resolved conflict to apply on current 3.6-rc3 upstream tip. Signed-off-by: Yi Zou <yi.zou@intel.com> Cc: www.Open-FCoE.org <devel@open-fcoe.org> Cc: Tomas Henzl <thenzl@redhat.com> Cc: <linux-scsi@vger.kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block')
-rw-r--r--block/blk-core.c8
1 files changed, 5 insertions, 3 deletions
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdfbca89..ee3cb3a5e278 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2254,9 +2254,11 @@ bool blk_update_request(struct request *req, int error, unsigned int nr_bytes)
2254 error_type = "I/O"; 2254 error_type = "I/O";
2255 break; 2255 break;
2256 } 2256 }
2257 printk(KERN_ERR "end_request: %s error, dev %s, sector %llu\n", 2257 printk_ratelimited(KERN_ERR "end_request: %s error, dev %s, sector %llu\n",
2258 error_type, req->rq_disk ? req->rq_disk->disk_name : "?", 2258 error_type, req->rq_disk ?
2259 (unsigned long long)blk_rq_pos(req)); 2259 req->rq_disk->disk_name : "?",
2260 (unsigned long long)blk_rq_pos(req));
2261
2260 } 2262 }
2261 2263
2262 blk_account_io_completion(req, nr_bytes); 2264 blk_account_io_completion(req, nr_bytes);