]> git.baikalelectronics.ru Git - kernel.git/commit
md: report 'write_pending' state when array in sync
authorTomasz Majchrzak <tomasz.majchrzak@intel.com>
Mon, 24 Oct 2016 10:47:28 +0000 (12:47 +0200)
committerShaohua Li <shli@fb.com>
Mon, 24 Oct 2016 22:28:19 +0000 (15:28 -0700)
commitd73584ebaa3c35178f338431f2436511ab00e0e8
tree7b4475d2ce077a19be5abefd02d8d9783d546dde
parente8f2668edb481ee7627744d8eec292195dbbe171
md: report 'write_pending' state when array in sync

If there is a bad block on a disk and there is a recovery performed from
this disk, the same bad block is reported for a new disk. It involves
setting MD_CHANGE_PENDING flag in rdev_set_badblocks. For external
metadata this flag is not being cleared as array state is reported as
'clean'. The read request to bad block in RAID5 array gets stuck as it
is waiting for a flag to be cleared - as per commit f2e95e5d5f18
("md/raid5: ensure device failure recorded before write request
returns.").

The meaning of MD_CHANGE_PENDING and MD_CHANGE_CLEAN flags has been
clarified in commit 8e3c1ddf510f ("md: resolve confusion of
MD_CHANGE_CLEAN"), however MD_CHANGE_PENDING flag has been used in
personality error handlers since and it doesn't fully comply with
initial purpose. It was supposed to notify that write request is about
to start, however now it is also used to request metadata update.
Initially (in md_allow_write, md_write_start) MD_CHANGE_PENDING flag has
been set and in_sync has been set to 0 at the same time. Error handlers
just set the flag without modifying in_sync value. Sysfs array state is
a single value so now it reports 'clean' when MD_CHANGE_PENDING flag is
set and in_sync is set to 1. Userspace has no idea it is expected to
take some action.

Swap the order that array state is checked so 'write_pending' is
reported ahead of 'clean' ('write_pending' is a misleading name but it
is too late to rename it now).

Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Signed-off-by: Shaohua Li <shli@fb.com>
drivers/md/md.c