summaryrefslogtreecommitdiffstats
path: root/crypto
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2012-05-22 13:53:47 +1000
committerNeilBrown <neilb@suse.de>2012-05-22 13:53:47 +1000
commit3ea7daa5d7fde47cd41f4d56c2deb949114da9d6 (patch)
tree8b88c2f7451219cd32f32753100ffc62cbda9c60 /crypto
parentdeb200d08590622d987718135a1e6323f83154aa (diff)
downloadlinux-3ea7daa5d7fde47cd41f4d56c2deb949114da9d6.tar.gz
linux-3ea7daa5d7fde47cd41f4d56c2deb949114da9d6.tar.bz2
linux-3ea7daa5d7fde47cd41f4d56c2deb949114da9d6.zip
md/raid10: add reshape support
A 'near' or 'offset' lay RAID10 array can be reshaped to a different 'near' or 'offset' layout, a different chunk size, and a different number of devices. However the number of copies cannot change. Unlike RAID5/6, we do not support having user-space backup data that is being relocated during a 'critical section'. Rather, the data_offset of each device must change so that when writing any block to a new location, it will not over-write any data that is still 'live'. This means that RAID10 reshape is not supportable on v0.90 metadata. The different between the old data_offset and the new_offset must be at least the larger of the chunksize multiplied by offset copies of each of the old and new layout. (for 'near' mode, offset_copies == 1). A larger difference of around 64M seems useful for in-place reshapes as more data can be moved between metadata updates. Very large differences (e.g. 512M) seem to slow the process down due to lots of long seeks (on oldish consumer graded devices at least). Metadata needs to be updated whenever the place we are about to write to is considered - by the current metadata - to still contain data in the old layout. [unbalanced locking fix from Dan Carpenter <dan.carpenter@oracle.com>] Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions