diff options
| author |   NeilBrown <neilb@suse.de> | 2010-08-30 17:33:34 +1000 |
|---|---|---|
| committer | NeilBrown <neilb@suse.de> | 2010-08-30 18:06:21 +1000 |
| commit | 070dc6dd7103b6b3f7e4d46e754354a5c15f366e (patch) | |
| tree | 173e72d08b2070d496c203a6d5156b9a2ad2808c /drivers/md/bitmap.c | |
| parent | md: don't clear MD_CHANGE_CLEAN in md_update_sb() for external arrays (diff) | |
| download | linux-dev-070dc6dd7103b6b3f7e4d46e754354a5c15f366e.tar.xz linux-dev-070dc6dd7103b6b3f7e4d46e754354a5c15f366e.zip | |
md: resolve confusion of MD_CHANGE_CLEAN
MD_CHANGE_CLEAN is used for two different purposes and this leads to
confusion.
One of the purposes is largely mirrored by MD_CHANGE_PENDING which is
not used for anything else, so have MD_CHANGE_PENDING take over that
purpose fully.
The two purposes are:
1/ tell md_update_sb that an update is needed and that it is just a
clean/dirty transition.
2/ tell user-space that an transition from clean to dirty is pending
(something wants to write), and tell te kernel (by clearin the
flag) that the transition is OK.
The first purpose remains wit MD_CHANGE_CLEAN, the second is moved
fully to MD_CHANGE_PENDING.
This means that various places which conditionally set or cleared
MD_CHANGE_CLEAN no longer need to be conditional.
Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/md/bitmap.c')
| -rw-r--r-- | drivers/md/bitmap.c | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c index 1ba1e122e948..ed4900ade93a 100644 --- a/drivers/md/bitmap.c +++ b/drivers/md/bitmap.c @@ -1542,8 +1542,7 @@ void bitmap_cond_end_sync(struct bitmap *bitmap, sector_t sector) atomic_read(&bitmap->mddev->recovery_active) == 0); bitmap->mddev->curr_resync_completed = bitmap->mddev->curr_resync; - if (bitmap->mddev->persistent) - set_bit(MD_CHANGE_CLEAN, &bitmap->mddev->flags); + set_bit(MD_CHANGE_CLEAN, &bitmap->mddev->flags); sector &= ~((1ULL << CHUNK_BLOCK_SHIFT(bitmap)) - 1); s = 0; while (s < sector && s < bitmap->mddev->resync_max_sectors) { |