md: handle_stripe5 - add request/completion logic for async check ops
authorDan Williams <dan.j.williams@intel.com>
Tue, 2 Jan 2007 20:52:31 +0000 (13:52 -0700)
committerDan Williams <dan.j.williams@intel.com>
Fri, 13 Jul 2007 15:06:17 +0000 (08:06 -0700)
commite89f89629b5de76e504d1be75c82c4a6b2419583
tree96f54c576f51207e4f4a75f4770e9cf2707fc948
parentf38e12199a94ca458e4f03c5a2c984fb80adadc5
md: handle_stripe5 - add request/completion logic for async check ops

Check operations are scheduled when the array is being resynced or an
explicit 'check/repair' command was sent to the array.  Previously check
operations would destroy the parity block in the cache such that even if
parity turned out to be correct the parity block would be marked
!R5_UPTODATE at the completion of the check.  When the operation can be
carried out by a dma engine the assumption is that it can check parity as a
read-only operation.  If raid5_run_ops notices that the check was handled
by hardware it will preserve the R5_UPTODATE status of the parity disk.

When a check operation determines that the parity needs to be repaired we
reuse the existing compute block infrastructure to carry out the operation.
Repair operations imply an immediate write back of the data, so to
differentiate a repair from a normal compute operation the
STRIPE_OP_MOD_REPAIR_PD flag is added.

Changelog:
* remove test_and_set/test_and_clear BUG_ONs, Neil Brown

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-By: NeilBrown <neilb@suse.de>
drivers/md/raid5.c