From: NeilBrown <neilb@suse.de>
To: "Alexander Kühn" <alexander.kuehn@nagilum.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: sync action not working/ignored
Date: Wed, 26 Sep 2012 11:47:39 +1000 [thread overview]
Message-ID: <20120926114739.7527aa1c@notabene.brown> (raw)
In-Reply-To: <20120923002734.Horde.j1X3SZk8pphQXjtWHRF5P_A@cakebox.homeunix.net>
[-- Attachment #1: Type: text/plain, Size: 4712 bytes --]
On Sun, 23 Sep 2012 00:27:34 +0200 Alexander Kühn
<alexander.kuehn@nagilum.de> wrote:
> Hi,
> for some reason linux appears to be ignoring my sync_action requests:
> root@nas:~# uname -a
> Linux nas 3.5.4 #1 SMP Sat Sep 15 15:41:21 CEST 2012 x86_64 GNU/Linux
> root@nas:~# echo /sys/block/md*/md/sync_action
> /sys/block/md1/md/sync_action
> root@nas:~# cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md1 : active (auto-read-only) raid5 sdb[5] sdg[9] sdd[7] sdf[6] sde[8]
> sdc[2] sda[1]
> 11719408128 blocks super 1.2 level 5, 64k chunk, algorithm 2
> [7/7] [UUUUUUU]
> bitmap: 0/15 pages [0KB], 65536KB chunk
>
> unused devices: <none>
> root@nas:~# echo check >/sys/block/md1/md/sync_action
> root@nas:~# cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md1 : active (auto-read-only) raid5 sdb[5] sdg[9] sdd[7] sdf[6] sde[8]
> sdc[2] sda[1]
> 11719408128 blocks super 1.2 level 5, 64k chunk, algorithm 2
> [7/7] [UUUUUUU]
> bitmap: 0/15 pages [0KB], 65536KB chunk
>
> unused devices: <none>
> root@nas:~# echo repair >/sys/block/md1/md/sync_action
> root@nas:~# cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md1 : active (auto-read-only) raid5 sdb[5] sdg[9] sdd[7] sdf[6] sde[8]
> sdc[2] sda[1]
> 11719408128 blocks super 1.2 level 5, 64k chunk, algorithm 2
> [7/7] [UUUUUUU]
> bitmap: 0/15 pages [0KB], 65536KB chunk
>
> unused devices: <none>
> root@nas:~# mdadm -Q --detail /dev/md1
> /dev/md1:
> Version : 1.2
> Creation Time : Thu Sep 9 20:43:43 2010
> Raid Level : raid5
> Array Size : 11719408128 (11176.50 GiB 12000.67 GB)
> Used Dev Size : 1953234688 (1862.75 GiB 2000.11 GB)
> Raid Devices : 7
> Total Devices : 7
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Sat Sep 22 23:28:50 2012
> State : active
> Active Devices : 7
> Working Devices : 7
> Failed Devices : 0
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Name : nas:1 (local to host nas)
> UUID : 5dbc572f:0e6b18bd:125db183:3511c054
> Events : 109708
>
> Number Major Minor RaidDevice State
> 5 8 16 0 active sync /dev/sdb
> 1 8 0 1 active sync /dev/sda
> 2 8 32 2 active sync /dev/sdc
> 8 8 64 3 active sync /dev/sde
> 6 8 80 4 active sync /dev/sdf
> 7 8 48 5 active sync /dev/sdd
> 9 8 96 6 active sync /dev/sdg
>
> Nothing in dmesg/syslog.
> No idea what's going on. :(
Thanks for the report.
I've queued up a patch which will cause changes to sync_action to clear the
read-auto status.
NeilBrown
From f1b6162a19c8217acd7762de03eeb80cea6d399b Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.de>
Date: Wed, 26 Sep 2012 11:46:00 +1000
Subject: [PATCH] md: writing to sync_action should clear the read-auto state.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In some cases array are started in 'read-auto' state where in
nothing gets written to any device until the array is written
to. The purpose of this is to make accidental auto-assembly
of the wrong arrays less of a risk, and to allow arrays to be
started to read suspend-to-disk images without actually changing
anything (as might happen if the array were dirty and a
resync seemed necessary).
Explicitly writing the 'sync_action' for a read-auto array currently
doesn't clear the read-auto state, so the sync action doesn't
happen, which can be confusing.
So allow any successful write to sync_action to clear any read-auto
state.
Reported-by: Alexander Kühn <alexander.kuehn@nagilum.de>
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 373b3eb..e868f0c 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4296,6 +4296,13 @@ action_store(struct mddev *mddev, const char *page, size_t len)
set_bit(MD_RECOVERY_REQUESTED, &mddev->recovery);
set_bit(MD_RECOVERY_SYNC, &mddev->recovery);
}
+ if (mddev->ro == 2) {
+ /* A write to sync_action is enough to justify
+ * canceling read-auto mode
+ */
+ mddev->ro = 0;
+ md_wakeup_thread(mddev->sync_thread);
+ }
set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
md_wakeup_thread(mddev->thread);
sysfs_notify_dirent_safe(mddev->sysfs_action);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2012-09-26 1:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-22 22:27 sync action not working/ignored Alexander Kühn
2012-09-23 5:59 ` Mikael Abrahamsson
2012-09-24 7:48 ` Sebastian Riemer
2012-09-26 1:47 ` NeilBrown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120926114739.7527aa1c@notabene.brown \
--to=neilb@suse.de \
--cc=alexander.kuehn@nagilum.de \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).