summaryrefslogtreecommitdiff
path: root/drivers/devfreq/governor_simpleondemand.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2011-12-23 09:57:48 +1100
committerNeilBrown <neilb@suse.de>2011-12-23 09:57:48 +1100
commit961902c0f8240175729274cd14198872f42072b7 (patch)
tree808b47d32174e970465dc00cea9150ff978bfc95 /drivers/devfreq/governor_simpleondemand.c
parent60fc13702a1b35118c1548e9c257fa038cecb658 (diff)
md/bitmap: It is OK to clear bits during recovery.
commit d0a4bb492772ce5c4bdfba3744a99ed6f6fb238f introduced a regression which is annoying but fairly harmless. When writing to an array that is undergoing recovery (a spare in being integrated into the array), writing to the array will set bits in the bitmap, but they will not be cleared when the write completes. For bits covering areas that have not been recovered yet this is not a problem as the recovery will clear the bits. However bits set in already-recovered region will stay set and never be cleared. This doesn't risk data integrity. The only negatives are: - next time there is a crash, more resyncing than necessary will be done. - the bitmap doesn't look clean, which is confusing. While an array is recovering we don't want to update the 'events_cleared' setting in the bitmap but we do still want to clear bits that have very recently been set - providing they were written to the recovering device. So split those two needs - which previously both depended on 'success' and always clear the bit of the write went to all devices. Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/devfreq/governor_simpleondemand.c')
0 files changed, 0 insertions, 0 deletions