summaryrefslogtreecommitdiffstats
path: root/drivers/md/raid6algos.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2008-08-05 15:54:14 +1000
committerNeilBrown <neilb@suse.de>2008-08-05 15:56:32 +1000
commit0310fa216decc3ecfab41f327638fa48a81f3735 (patch)
tree86fc2736802c55de2e21a4e223c34d9e8a1e93a2 /drivers/md/raid6algos.c
parentc89a8eee61540df04fc83f32f51ef0f46ec018b1 (diff)
downloadop-kernel-dev-0310fa216decc3ecfab41f327638fa48a81f3735.zip
op-kernel-dev-0310fa216decc3ecfab41f327638fa48a81f3735.tar.gz
Allow raid10 resync to happening in larger chunks.
The raid10 resync/recovery code currently limits the amount of in-flight resync IO to 2Meg. This was copied from raid1 where it seems quite adequate. However for raid10, some layouts require a bit of seeking to perform a resync, and allowing a larger buffer size means that the seeking can be significantly reduced. There is probably no real need to limit the amount of in-flight IO at all. Any shortage of memory will naturally reduce the amount of buffer space available down to a set minimum, and any concurrent normal IO will quickly cause resync IO to back off. The only problem would be that normal IO has to wait for all resync IO to finish, so a very large amount of resync IO could cause unpleasant latency when normal IO starts up. So: increase RESYNC_DEPTH to allow 32Meg of buffer (if memory is available) which seems to be a good amount. Also reduce the amount of memory reserved as there is no need to keep 2Meg just for resync if memory is tight. Thanks to Keld for the suggestion. Cc: Keld Jørn Simonsen <keld@dkuug.dk> Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/md/raid6algos.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud