summaryrefslogtreecommitdiff
path: root/drivers/scsi/a100u2w.c
diff options
context:
space:
mode:
authorLars Ellenberg <lars.ellenberg@linbit.com>2012-09-03 13:48:21 (GMT)
committerJens Axboe <axboe@kernel.dk>2012-10-30 07:39:17 (GMT)
commit7fb907c15fb8d0e10e72c8566a13f6defab3f484 (patch)
tree60cf652915f97cb84e842c3e173f2729e0baac72 /drivers/scsi/a100u2w.c
parentdbd0820c6f7b7db9a97d63ea379fc174a63ddbca (diff)
downloadlinux-7fb907c15fb8d0e10e72c8566a13f6defab3f484.tar.xz
drbd: panic on delayed completion of aborted requests
"aborting" requests, or force-detaching the disk, is intended for completely blocked/hung local backing devices which do no longer complete requests at all, not even do error completions. In this situation, usually a hard-reset and failover is the only way out. By "aborting", basically faking a local error-completion, we allow for a more graceful swichover by cleanly migrating services. Still the affected node has to be rebooted "soon". By completing these requests, we allow the upper layers to re-use the associated data pages. If later the local backing device "recovers", and now DMAs some data from disk into the original request pages, in the best case it will just put random data into unused pages; but typically it will corrupt meanwhile completely unrelated data, causing all sorts of damage. Which means delayed successful completion, especially for READ requests, is a reason to panic(). We assume that a delayed *error* completion is OK, though we still will complain noisily about it. Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/scsi/a100u2w.c')
0 files changed, 0 insertions, 0 deletions