From: Bill Davidsen <davidsen@tmr.com>
To: Michael Guntsche <mike@it-loops.com>
Cc: Robin Hill <robin@robinhill.me.uk>, linux-raid@vger.kernel.org
Subject: Re: Strange RAID-5 rebuild problem
Date: Mon, 03 Mar 2008 12:53:10 -0500 [thread overview]
Message-ID: <47CC3B06.7050708@tmr.com> (raw)
In-Reply-To: <A5F6B52A-00BB-4096-9A8D-367F61989186@it-loops.com>
Michael Guntsche wrote:
>
> On Mar 1, 2008, at 23:41, Michael Guntsche wrote:
>>
>> mdadm -w /dev/md1 works if I call it after assembling.
>> If do not call it, mount the array and start writing to it, it
>> changes to "active"
>> but the rebuild process does not kick in.
>>
>> The only way it works for me now is.
>> * Stop the array
>> * assemble it again with mdadm --assemble --scan
>> * Call mdadm -w /dev/md1
>
> Good morning,
>
> I found out why I am seeing this behaviour but I still do not know if
> it is a bug or not.
>
> The arrays are assembled in an initramfs. Debian's mdadm tool has a
> script that assembles the arrays.
>
> Now this script has the following entry.
>
> # prevent writes/syncs so that resuming works (#415441). See
> http:/bugs.debian.org/415441 for more information.
> echo 1 > /sys/module/md_mod/parameters/start_ro
>
> Changing this sysfs entry to 0, gives me the expected result if I do a
> stop -> assemble with my 1.0 array.
> It starts reysncing and everything is ok. According to the replies in
> this bug, setting start_ro to 1 should NOT stop the automatic resync
> after a write to it, but this seems to have changed now.
> So, is this a change in behaviour or is it a bug. If it is the former,
> I probably need to talk with the debian guys about it, if it is a bug
> I wait for a fix and comment the entry in the mean time.
Note that if you don't start_ro I don't believe you will be able to use
the resume feature. The use of -w option would seem safer. I haven't
looked at the patch Neil submitted to start rebuild/reshape at the first
write, the logic seems correct to work with resume, nothing should start
until a user write.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
next prev parent reply other threads:[~2008-03-03 17:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-01 21:09 Strange RAID-5 rebuild problem Michael Guntsche
2008-03-01 22:02 ` Michael Guntsche
[not found] ` <20080301222326.GA20435@cthulhu.home.robinhill.me.uk>
2008-03-01 22:41 ` Michael Guntsche
2008-03-02 7:38 ` Michael Guntsche
2008-03-02 8:14 ` Michael Guntsche
2008-03-02 10:09 ` Michael Tokarev
2008-03-02 10:20 ` Michael Guntsche
2008-03-03 0:33 ` Neil Brown
2008-03-03 12:38 ` Michael Guntsche
2008-03-02 12:29 ` Robin Hill
2008-03-02 20:55 ` Michael Guntsche
2008-03-03 17:53 ` Bill Davidsen [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-03-01 20:57 Michael Guntsche
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=47CC3B06.7050708@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-raid@vger.kernel.org \
--cc=mike@it-loops.com \
--cc=robin@robinhill.me.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.