linux-stable.git/drivers/md/raid10.c, branch v3.4.8

md/raid10: fix failure when trying to repair a read error.

2012-07-16T16:04:25+00:00

commit 055d3747dbf00ce85c6872ecca4d466638e80c22 upstream.

commit 58c54fcca3bac5bf9290cfed31c76e4c4bfbabaf
     md/raid10: handle further errors during fix_read_error better.

in 3.1 added "r10_sync_page_io" which takes an IO size in sectors.
But we were passing the IO size in bytes!!!
This resulting in bio_add_page failing, and empty request being sent
down, and a consequent BUG_ON in scsi_lib.

[fix missing space in error message at same time]

This fix is suitable for 3.1.y and later.

Reported-by: Christian Balzer 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: Don't try to recovery unmatched (and unused) chunks.

2012-07-16T16:04:25+00:00

commit fc448a18ae6219af9a73257b1fbcd009efab4a81 upstream.

If a RAID10 has an odd number of chunks - as might happen when there
are an odd number of devices - the last chunk has no pair and so is
not mirrored.  We don't store data there, but when recovering the last
device in an array we retry to recover that last chunk from a
non-existent location.  This results in an error, and the recovery
aborts.

When we get to that last chunk we should just stop - there is nothing
more to do anyway.

This bug has been present since the introduction of RAID10, so the
patch is appropriate for any -stable kernel.

Reported-by: Christian Balzer 
Tested-by: Christian Balzer 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: raid1/raid10: fix problem with merge_bvec_fn

2012-06-09T15:36:18+00:00

commit aba336bd1d46d6b0404b06f6915ed76150739057 upstream.

The new merge_bvec_fn which calls the corresponding function
in subsidiary devices requires that mddev->merge_check_needed
be set if any child has a merge_bvec_fn.

However were were only setting that when a device was hot-added,
not when a device was present from the start.

This bug was introduced in 3.4 so patch is suitable for 3.4.y
kernels.  However that are conflicts in raid10.c so a separate
patch will be needed for 3.4.y.

Reported-by: Sebastian Riemer 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: fix transcription error in calc_sectors conversion.

2012-05-18T23:01:13+00:00

The old code was
		sector_div(stride, fc);
the new code was
		sector_dir(size, conf->near_copies);

'size' is right (the stride various wasn't really needed), but
'fc' means 'far_copies', and that is an important difference.

Signed-off-by: NeilBrown

md/raid10: set dev_sectors properly when resizing devices in array.

2012-05-17T00:08:45+00:00

raid10 stores dev_sectors in 'conf' separately from the one in
'mddev' because it can have a very significant effect on block
addressing and so need to be updated carefully.

However raid10_resize isn't updating it at all!

To update it correctly, we need to make sure it is a proper
multiple of the chunksize taking various details of the layout
in to account.
This calculation is currently done in setup_conf.   So split it
out from there and call it from raid10_resize as well.
Then set conf->dev_sectors properly.

Signed-off-by: NeilBrown

md/raid1,raid10: Fix calculation of 'vcnt' when processing error recovery.

2012-04-12T06:04:47+00:00

If r1bio->sectors % 8 != 0,then the memcmp and a later
memcpy will omit the last bio_vec.

This is suitable for any stable kernel since 3.1 when bad-block
management was introduced.

Cc: stable@vger.kernel.org
Signed-off-by: majianpeng 
Signed-off-by: NeilBrown

md/raid1,raid10: don't compare excess byte during consistency check.

2012-04-03T05:39:23+00:00

When comparing two pages read from different legs of a mirror, only
compare the bytes that were read, not the whole page.

In most cases we read a whole page, but in some cases with
bad blocks or odd sizes devices we might read fewer than that.

This bug has been present "forever" but at worst it might cause
a report of two many mismatches and generate a little bit
extra resync IO, so there is no need to back-port to -stable
kernels.

Reported-by: majianpeng 
Signed-off-by: NeilBrown

md/raid10 - support resizing some RAID10 arrays.

2012-03-19T01:46:40+00:00

'resizing' an array in this context means making use of extra
space that has become available in component devices, not adding new
devices.
It also includes shrinking the array to take up less space of
component devices.

This is not supported for array with a 'far' layout.  However
for 'near' and 'offset' layout arrays, adding and removing space at
the end of the devices is easy to support, and this patch provides
that support.

Signed-off-by: NeilBrown

md/raid10: handle merge_bvec_fn in member devices.

2012-03-19T01:46:39+00:00

Currently we don't honour merge_bvec_fn in member devices so if there
is one, we force all requests to be single-page at most.
This is not ideal.

So enhance the raid10 merge_bvec_fn to check that function in children
as well.

This introduces a small problem.  There is no locking around calls
the ->merge_bvec_fn and subsequent calls to ->make_request.  So a
device added between these could end up getting a request which
violates its merge_bvec_fn.

Currently the best we can do is synchronize_sched().  This will work
providing no preemption happens.  If there is preemption, we just
have to hope that new devices are largely consistent with old devices.

Signed-off-by: NeilBrown

md: tidy up rdev_for_each usage.

2012-03-19T01:46:39+00:00

md.h has an 'rdev_for_each()' macro for iterating the rdevs in an
mddev.  However it uses the 'safe' version of list_for_each_entry,
and so requires the extra variable, but doesn't include 'safe' in the
name, which is useful documentation.

Consequently some places use this safe version without needing it, and
many use an explicity list_for_each entry.

So:
 - rename rdev_for_each to rdev_for_each_safe
 - create a new rdev_for_each which uses the plain
   list_for_each_entry,
 - use the 'safe' version only where needed, and convert all other
   list_for_each_entry calls to use rdev_for_each.

Signed-off-by: NeilBrown