linux/drivers/md/raid1.c, branch v3.4-rc2

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

2012-04-03T05:39:23Z

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/raid1:Remove unnecessary rcu_dereference(conf->mirrors[i].rdev).

2012-04-03T05:37:33Z

Because rde->nr_pending > 0,so can not remove this disk. And in any case, we aren't holding rcu_read_lock() Signed-off-by: majianpeng Signed-off-by: NeilBrown

md/raid1: If md_integrity_register() failed,run() must free the mem

2012-04-01T23:48:38Z

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

md/raid1: handle merge_bvec_fn in member devices.

2012-03-19T01:46:39Z

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 create a raid1 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 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:39Z

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

md/raid1,raid10: avoid deadlock during resync/recovery.

2012-03-19T01:46:38Z

If RAID1 or RAID10 is used under LVM or some other stacking block device, it is possible to enter a deadlock during resync or recovery. This can happen if the upper level block device creates two requests to the RAID1 or RAID10. The first request gets processed, blocks recovery and queue requests for underlying requests in current->bio_list. A resync request then starts which will wait for those requests and block new IO. But then the second request to the RAID1/10 will be attempted and it cannot progress until the resync request completes, which cannot progress until the underlying device requests complete, which are on a queue behind that second request. So allow that second request to proceed even though there is a resync request about to start. This is suitable for any -stable kernel. Cc: stable@vger.kernel.org Reported-by: Ray Morris Tested-by: Ray Morris Signed-off-by: NeilBrown

md/raid1: fix buglet in md_raid1_contested.

2012-02-13T03:24:05Z

Since we added 'replacement' capability, RAID1 can have twice as many devices as ->raid_disks indicates. So md_raid1_congested needs to check that many possible devices, not just ->raid_disks many. Signed-off-by: NeilBrown

md/raid1: perform bad-block tests for WriteMostly devices too.

2012-01-10T21:35:17Z

We normally try to avoid reading from write-mostly devices, but when we do we really have to check for bad blocks and be sure not to try reading them. With the current code, best_good_sectors might not get set and that causes zero-length read requests to be send down which is very confusing. This bug was introduced in commit d2eb35acfdccbe2 and so the patch is suitable for 3.1.x and 3.2.x Reported-and-tested-by: Michał Mirosław Reported-and-tested-by: Art -kwaak- van Breemen Signed-off-by: NeilBrown Cc: stable@vger.kernel.org

md/raid1: Mark device want_replacement when we see a write error.

2011-12-22T23:17:57Z

Now that WantReplacement drives are replaced cleanly, mark a drive as want_replacement when we see a write error. It might get failed soon so the WantReplacement flag is irrelevant, but if the write error is recorded in the bad block log, we still want to activate any spare that might be available. Signed-off-by: NeilBrown

md/raid1: If there is a spare and a want_replacement device, start replacement.

2011-12-22T23:17:57Z

When attempting to add a spare to a RAID1 array, also consider adding it as a replacement for a want_replacement device. Signed-off-by: NeilBrown