linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* mdadm --wait doesn't
@ 2009-07-05 17:35 Jon Nelson
  2009-07-05 20:54 ` John Robinson
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Nelson @ 2009-07-05 17:35 UTC (permalink / raw)
  To: LinuxRaid

I was trying to use mdadm --wait a bit ago to wait for a recovery
operation, but mdadm --wait didn't actually wait.

Here is md12 after adding /dev/sdf1 back to it.

md12 : active raid1 sdf1[3] nbd0[2](W)(F) sde[0]
      72612988 blocks super 1.1 [3/1] [U__]
      [>....................]  recovery =  3.0% (2195456/72612988)
finish=51.4min speed=22805K/sec
      bitmap: 139/139 pages [556KB], 256KB chunk

However, mdadm /dev/md12 --wait (and --wait-clean) did not wait for
the recovery to be complete.

turnip:~ # mdadm /dev/md12 --wait
turnip:~ # echo $?
0
turnip:~ # mdadm --version
mdadm - v3.0 - 2nd June 2009

I would --fail and --remove /dev/sdf1 and try again (with --add), and
I did this several times, and I could not get it to wait until the
recovery was complete.

Am I doing something wrong? Did I mis-read the documentation?

kernel: 2.6.27.23, x86_64, openSUSE 11.1 "default" kernel.
mdadm version compiled out of latest git.


-- 
Jon

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: mdadm --wait doesn't
  2009-07-05 17:35 mdadm --wait doesn't Jon Nelson
@ 2009-07-05 20:54 ` John Robinson
  2009-07-05 21:37   ` Jon Nelson
  0 siblings, 1 reply; 4+ messages in thread
From: John Robinson @ 2009-07-05 20:54 UTC (permalink / raw)
  To: Jon Nelson; +Cc: LinuxRaid

On 05/07/2009 18:35, Jon Nelson wrote:
> I was trying to use mdadm --wait a bit ago to wait for a recovery
> operation, but mdadm --wait didn't actually wait.
> 
> Here is md12 after adding /dev/sdf1 back to it.
> 
> md12 : active raid1 sdf1[3] nbd0[2](W)(F) sde[0]
>       72612988 blocks super 1.1 [3/1] [U__]
>       [>....................]  recovery =  3.0% (2195456/72612988)
> finish=51.4min speed=22805K/sec
>       bitmap: 139/139 pages [556KB], 256KB chunk
> 
> However, mdadm /dev/md12 --wait (and --wait-clean) did not wait for
> the recovery to be complete.
> 
> turnip:~ # mdadm /dev/md12 --wait
> turnip:~ # echo $?
> 0
> turnip:~ # mdadm --version
> mdadm - v3.0 - 2nd June 2009
> 
> I would --fail and --remove /dev/sdf1 and try again (with --add), and
> I did this several times, and I could not get it to wait until the
> recovery was complete.
> 
> Am I doing something wrong? Did I mis-read the documentation?

Did you try `mdadm --wait /dev/md12`? For me that returns 1 on a 
fully-up array (where there's nothing to wait for) while `mdadm 
/dev/md12 --wait` returns 0, so they're obviously handled differently. I 
don't really feel like degrading an array to test further, I'll leave it 
to you :-)

Cheers,

John.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: mdadm --wait doesn't
  2009-07-05 20:54 ` John Robinson
@ 2009-07-05 21:37   ` Jon Nelson
  2009-07-05 22:28     ` NeilBrown
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Nelson @ 2009-07-05 21:37 UTC (permalink / raw)
  Cc: LinuxRaid

On Sun, Jul 5, 2009 at 3:54 PM, John
Robinson<john.robinson@anonymous.org.uk> wrote:
> On 05/07/2009 18:35, Jon Nelson wrote:
>>
>> I was trying to use mdadm --wait a bit ago to wait for a recovery
>> operation, but mdadm --wait didn't actually wait.
>>
>> Here is md12 after adding /dev/sdf1 back to it.
>>
>> md12 : active raid1 sdf1[3] nbd0[2](W)(F) sde[0]
>>      72612988 blocks super 1.1 [3/1] [U__]
>>      [>....................]  recovery =  3.0% (2195456/72612988)
>> finish=51.4min speed=22805K/sec
>>      bitmap: 139/139 pages [556KB], 256KB chunk
>>
>> However, mdadm /dev/md12 --wait (and --wait-clean) did not wait for
>> the recovery to be complete.
>>
>> turnip:~ # mdadm /dev/md12 --wait
>> turnip:~ # echo $?
>> 0
>> turnip:~ # mdadm --version
>> mdadm - v3.0 - 2nd June 2009
>>
>> I would --fail and --remove /dev/sdf1 and try again (with --add), and
>> I did this several times, and I could not get it to wait until the
>> recovery was complete.
>>
>> Am I doing something wrong? Did I mis-read the documentation?
>
> Did you try `mdadm --wait /dev/md12`? For me that returns 1 on a fully-up
> array (where there's nothing to wait for) while `mdadm /dev/md12 --wait`
> returns 0, so they're obviously handled differently. I don't really feel
> like degrading an array to test further, I'll leave it to you :-)

OK, that's weird. mdadm /dev/md12 --wait doesn't, while mdadm --wait
/dev/md12 does.
That doesn't seem right to me.

-- 
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: mdadm --wait doesn't
  2009-07-05 21:37   ` Jon Nelson
@ 2009-07-05 22:28     ` NeilBrown
  0 siblings, 0 replies; 4+ messages in thread
From: NeilBrown @ 2009-07-05 22:28 UTC (permalink / raw)
  To: Jon Nelson; +Cc: ""@neil.brown.name, LinuxRaid

On Mon, July 6, 2009 7:37 am, Jon Nelson wrote:

> OK, that's weird. mdadm /dev/md12 --wait doesn't, while mdadm --wait
> /dev/md12 does.
> That doesn't seem right to me.

That's what I get for overloading the single-letter args.
Bother --wait and --write-mostly can be given as -W, and mdadm doesn't
distinguish between those three internally.
So
  mdadm /dev/md12 -wait
chooses MANAGE mode and the --wait is treated like --write-mostly,
and as you haven't given any drives to add in write-mostly mode,
it doesn't nothing.

I probably should fix that one day.

NeilBrown


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-07-05 22:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-05 17:35 mdadm --wait doesn't Jon Nelson
2009-07-05 20:54 ` John Robinson
2009-07-05 21:37   ` Jon Nelson
2009-07-05 22:28     ` NeilBrown

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).