linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roger Heflin <rogerheflin@gmail.com>
To: Richard Michael <rmichael-raid@edgeofthenet.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: Why can't I stop these arrays?
Date: Sun, 22 Jun 2008 17:58:01 -0500	[thread overview]
Message-ID: <485ED8F9.70203@gmail.com> (raw)
In-Reply-To: <20080622223517.GD5474@nexus.edgeofthenet.org>

Richard Michael wrote:
> I am experimenting with various array configurations.  I have several
> arrays running and I want to stop them.  They are not mounted; indeed,
> they don't even have filesystems on them.  As far as I can tell, nothing
> on the system is using them.
> 
> I have tried stopping the monitoring mdadm process, but I still cannot
> stop the arrays.  (Although, if it was necessary to stop the monitoring
> process for all arrays just to stop one of them, that would be a bug.)
> 
> There is a raid5 resyncing, which might be causing the problem (although
> it shouldn't), but it needs hours to finish the resync.  Also, none of
> the components in the raid5 array are in the arrays I want to stop, so
> again, I don't see why there should be a problem.
> 
> (Though, md3 is also a raid5 and md5 is comprised of md3, so in some
> sense md5 also "has something to do with" raid5.  Problem?)
> 
> Aside, how can I stop the resync to test if it is interferring?  Note,
> the system is running of the resyncing raid5, so I need to stop the
> resync but *not* stop the array.
> 
> Any advice?  Probably I've missed something obvious..
> 
> 
> [root@server ~]# cat /proc/mdstat 
> Personalities : [raid6] [raid5] [raid4] [raid1] 
> md5 : active raid1 md3[0]
>       1952475584 blocks [2/1] [U_]
>       
> md3 : active raid5 sdd2[0] sdg2[3](S) sdf2[2] sde2[1]
>       1952475648 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>       
> md0 : active raid1 sda1[0] sdb1[1]
>       521984 blocks [3/2] [UU_]
>       
> md1 : active raid5 sdc2[3] sda2[0] sdb2[1]
>       1952475648 blocks level 5, 256k chunk, algorithm 2 [3/2] [UU_]
>       [=======>.............]  recovery = 35.9% (351008004/976237824)
> finish=163.5min speed=63727K/sec
>       
> unused devices: <none>
> [root@server ~]# mdadm --stop /dev/md5
> mdadm: fail to stop array /dev/md5: Device or resource busy
> [root@server ~]# mdadm --stop /dev/md3
> mdadm: fail to stop array /dev/md3: Device or resource busy
> 

Do they have volume groups on them?

If so you need to turn them off.

I would "vgdisplay" and if they show up in there they will need to be turned off 
there before they can be unmounted (vgchange -a y device).

                       Roger

  reply	other threads:[~2008-06-22 22:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-22 22:35 Why can't I stop these arrays? Richard Michael
2008-06-22 22:58 ` Roger Heflin [this message]
2008-06-23  0:46   ` Why can't I stop these arrays? PATCH Richard Michael
2008-06-23 22:42     ` Neil Brown
2008-06-22 23:55 ` Why can't I stop these arrays? Mikael Abrahamsson

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=485ED8F9.70203@gmail.com \
    --to=rogerheflin@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=rmichael-raid@edgeofthenet.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).