linux/drivers/md/raid1.c, branch v5.4

md/raid1: fail run raid1 array when active disk less than one

2019-09-03T21:52:03Z

When run test case: mdadm -CR /dev/md1 -l 1 -n 4 /dev/sd[a-d] --assume-clean --bitmap=internal mdadm -S /dev/md1 mdadm -A /dev/md1 /dev/sd[b-c] --run --force mdadm --zero /dev/sda mdadm /dev/md1 -a /dev/sda echo offline > /sys/block/sdc/device/state echo offline > /sys/block/sdb/device/state sleep 5 mdadm -S /dev/md1 echo running > /sys/block/sdb/device/state echo running > /sys/block/sdc/device/state mdadm -A /dev/md1 /dev/sd[a-c] --run --force mdadm run fail with kernel message as follow: [ 172.986064] md: kicking non-fresh sdb from array! [ 173.004210] md: kicking non-fresh sdc from array! [ 173.022383] md/raid1:md1: active with 0 out of 4 mirrors [ 173.022406] md1: failed to create bitmap (-5) In fact, when active disk in raid1 array less than one, we need to return fail in raid1_run(). Reviewed-by: NeilBrown Signed-off-by: Yufen Yu Signed-off-by: Song Liu

raid1: factor out a common routine to handle the completion of sync write

2019-08-07T17:25:02Z

It's just code clean-up. Signed-off-by: Hou Tao Signed-off-by: Song Liu

md: allow last device to be forcibly removed from RAID1/RAID10.

2019-08-07T17:25:02Z

When the 'last' device in a RAID1 or RAID10 reports an error, we do not mark it as failed. This would serve little purpose as there is no risk of losing data beyond that which is obviously lost (as there is with RAID5), and there could be other sectors on the device which are readable, and only readable from this device. This in general this maximises access to data. However the current implementation also stops an admin from removing the last device by direct action. This is rarely useful, but in many case is not harmful and can make automation easier by removing special cases. Also, if an attempt to write metadata fails the device must be marked as faulty, else an infinite loop will result, attempting to update the metadata on all non-faulty devices. So add 'fail_last_dev' member to 'struct mddev', then we can bypasses the 'last disk' checks for RAID1 and RAID10, and control the behavior per array by change sysfs node. Signed-off-by: NeilBrown [add sysfs node for fail_last_dev by Guoqing] Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu

md/raid1: end bio when the device faulty

2019-08-07T17:25:02Z

When write bio return error, it would be added to conf->retry_list and wait for raid1d thread to retry write and acknowledge badblocks. In narrow_write_error(), the error bio will be split in the unit of badblock shift (such as one sector) and raid1d thread issues them one by one. Until all of the splited bio has finished, raid1d thread can go on processing other things, which is time consuming. But, there is a scene for error handling that is not necessary. When the device has been set faulty, flush_bio_list() may end bios in pending_bio_list with error status. Since these bios has not been issued to the device actually, error handlding to retry write and acknowledge badblocks make no sense. Even without that scene, when the device is faulty, badblocks info can not be written out to the device. Thus, we also no need to handle the error IO. Signed-off-by: Yufen Yu Signed-off-by: Song Liu

raid1: use an int as the return value of raise_barrier()

2019-08-07T17:25:02Z

Using a sector_t as the return value is misleading, because raise_barrier() only return 0 or -EINTR. Also add comments for the return values of raise_barrier(). Signed-off-by: Hou Tao Signed-off-by: Song Liu

md/raid1: Fix a warning message in remove_wb()

2019-06-26T19:18:48Z

The WARN_ON() macro doesn't take an error message, it just takes a condition. I've changed this to use WARN(1, "...") instead. Fixes: 3e148a320979 ("md/raid1: fix potential data inconsistency issue with write behind device") Signed-off-by: Dan Carpenter Signed-off-by: Song Liu

md/raid1: fix potential data inconsistency issue with write behind device

2019-06-20T23:35:59Z

For write-behind mode, we think write IO is complete once it has reached all the non-writemostly devices. It works fine for single queue devices. But for multiqueue device, if there are lots of IOs come from upper layer, then the write-behind device could issue those IOs to different queues, depends on the each queue's delay, so there is no guarantee that those IOs can arrive in order. To address the issue, we need to check the collision among write behind IOs, we can only continue without collision, otherwise wait for the completion of previous collisioned IO. And WBCollision is introduced for multiqueue device which is worked under write-behind mode. But this patch doesn't handle below cases which could have the data inconsistency issue as well, these cases will be handled in later patches. 1. modify max_write_behind by write backlog node. 2. add or remove array's bitmap dynamically. 3. the change of member disk. Reviewed-by: NeilBrown Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu

md: raid1-10: Unify r{1,10}bio_pool_free

2019-06-15T07:37:35Z

Avoiding duplicated code, since they just execute a kfree. Signed-off-by: Marcos Paulo de Souza Signed-off-by: Jens Axboe

md/raid1: get rid of extra blank line and space

2019-06-15T07:37:34Z

This patch get rid of extra blank line and space, and add necessary space for code. Signed-off-by: Yufen Yu Signed-off-by: Song Liu Signed-off-by: Jens Axboe

drivers: md: Unify common definitions of raid1 and raid10

2019-06-15T07:37:34Z

These definitions are being moved to raid1-10.c. Signed-off-by: Marcos Paulo de Souza Signed-off-by: Song Liu Signed-off-by: Jens Axboe