[PATCH] imsm: FIX: Raid5 data corruption data recovering from backup
am 10.06.2011 15:00:14 von adam.kwolekSporadicaly when Raid5's data are restored from backup area,
corruption occurs.
It doesn't happen if reshape process is beyond critical section.
Root cause of the problem is passing wrong starting point in
restore_stripes(). It was hard coded to 0 so far.
This causes that parity disks position in first stripe was always set
to the last raid disk. This position should depend on data position in array.
Proper start position was set and pointer for restoring data
(copy area address) is adjusted to passed start parameter.
Signed-off-by: Adam Kwolek
Signed-off-by: Krzysztof Wojcik
---
super-intel.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index 5e8b834..075385a 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -7718,6 +7718,8 @@ int save_backup_imsm(struct supertype *st,
int new_disks = map_dest->num_members;
int dest_layout = 0;
int dest_chunk;
+ unsigned long long start;
+ int data_disks = imsm_num_data_members(dev, 0);
targets = malloc(new_disks * sizeof(int));
if (!targets)
@@ -7727,10 +7729,15 @@ int save_backup_imsm(struct supertype *st,
if (!target_offsets)
goto abort;
+ start = info->reshape_progress * 512;
for (i = 0; i < new_disks; i++) {
targets[i] = -1;
target_offsets[i] = (unsigned long long)
__le32_to_cpu(super->migr_rec->ckpt_area_pba) * 512;
+ /* move back copy area adderss, it will be moved forward
+ * in restore_stripes() using start input variable
+ */
+ target_offsets[i] -= start/data_disks;
}
if (open_backup_targets(info, new_disks, targets))
@@ -7748,7 +7755,7 @@ int save_backup_imsm(struct supertype *st,
-1, /* source backup file descriptor */
0, /* input buf offset
* always 0 buf is already offseted */
- 0,
+ start,
length,
buf) != 0) {
fprintf(stderr, Name ": Error restoring stripes\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html