| commit | 26d0764d2bf7f6b8dcd5a99d85cc6b1c02b65da6 | |
| author | Neil Brown <neilb@suse.de> | |
| Wed, 22 Aug 2007 22:57:45 +0000 (23 00:57 +0200) | ||
| committer | Adrian Bunk <bunk@stusta.de> | |
| Wed, 22 Aug 2007 22:57:45 +0000 (23 00:57 +0200) | ||
| tree | af57b73a8dc853df1abf34ec6a183ca35404c0e9 | treesnapshot (tar.gz zip) |
| parent | 32b268195c968892eec3cdb328e2594e379a658b | commitdiff |
md: fix resync speed calculation for restarted resyncs
We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.
However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count. This is wrong because curr_resync counts all sectors,
not just io sectors.
So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.
However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count. This is wrong because curr_resync counts all sectors,
not just io sectors.
So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
| drivers/md/md.c | diffblobblamehistory | |
| include/linux/raid/md_k.h | diffblobblamehistory |