diff options
author | NeilBrown <neilb@suse.de> | 2011-05-11 15:52:21 +1000 |
---|---|---|
committer | NeilBrown <neilb@suse.de> | 2011-05-11 15:52:21 +1000 |
commit | b098636cf04c89db4036fedc778da0acc666ad1a (patch) | |
tree | 11a970bdc482b4e5cb2211eefb9a71ae34355bd3 /drivers/firmware | |
parent | ab9d47e990c12c11cc95ed1247a3782234a7e33a (diff) |
md: allow resync_start to be set while an array is active.
The sysfs attribute 'resync_start' (known internally as recovery_cp),
records where a resync is up to. A value of 0 means the array is
not known to be in-sync at all. A value of MaxSector means the array
is believed to be fully in-sync.
When the size of member devices of an array (RAID1,RAID4/5/6) is
increased, the array can be increased to match. This process sets
resync_start to the old end-of-device offset so that the new part of
the array gets resynced.
However with RAID1 (and RAID6) a resync is not technically necessary
and may be undesirable. So it would be good if the implied resync
after the array is resized could be avoided.
So: change 'resync_start' so the value can be changed while the array
is active, and as a precaution only allow it to be changed while
resync/recovery is 'frozen'. Changing it once resync has started is
not going to be useful anyway.
This allows the array to be resized without a resync by:
write 'frozen' to 'sync_action'
write new size to 'component_size' (this will set resync_start)
write 'none' to 'resync_start'
write 'idle' to 'sync_action'.
Also slightly improve some tests on recovery_cp when resizing
raid1/raid5. Now that an arbitrary value could be set we should be
more careful in our tests.
Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/firmware')
0 files changed, 0 insertions, 0 deletions