From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Lyakas Subject: Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active' Date: Fri, 2 Sep 2011 00:18:12 +0300 Message-ID: References: <20110830072557.428fab35@notabene.brown> <20110831105455.04fd585e@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20110831105455.04fd585e@notabene.brown> Sender: linux-raid-owner@vger.kernel.org To: NeilBrown Cc: linux-raid@vger.kernel.org List-Id: linux-raid.ids Thank you for looking at both issues, Neil. Alex. On Wed, Aug 31, 2011 at 3:54 AM, NeilBrown wrote: > On Tue, 30 Aug 2011 18:18:11 +0300 Alexander Lyakas > wrote: > >> Thanks, Neil. >> >> Although according to udev documentation: "the udev events are sent >> out after udev has finished its event processing, all rules have bee= n >> processed, and needed device nodes are created." >> >> Also looking at udev-worker code of udevd, the >> udev_monitor_send_device() call is done after all the rules have bee= n >> processed. >> >> Nevertheless, I looked at udevadm_settle.c and did some equivalent o= f >> that in my code, and it looks like the issue is resolved. Perhaps >> there is something md-specific here? > > I cannot see how it would be md-specific. =A0mdadm doesn't create or = remove > devices when udev is active - it leaves all that to udev. > If you are curious I suggest you ask the udev developers. > >> >> Another thing, since you are reading this thread, I wanted to ask >> whether you have any advice on the "RAID5: failing an active compone= nt >> during spare rebuild - arrays hangs" thread I opened some time ago. >> Since you were not answering, I assume there is nothing additional y= ou >> can advise about, correct? I apologize if this off-topic was >> inappropriate. > > It could mean that I had nothing extra to say, but it could also mean= that I > got distracted, forgot, and never got back to it. =A0I live in a worl= d of > distractions :-( > > But a reminder never hurts - it shows that it is important to you, so= that > makes it at least a little bit important to me. =A0I'll go back and h= ave a look > and see if I have anything useful to add. > > NeilBrown > > >> >> Thanks for the help, >> =A0 Alex. >> >> >> >> On Tue, Aug 30, 2011 at 12:25 AM, NeilBrown wrote: >> > On Mon, 29 Aug 2011 20:17:34 +0300 Alexander Lyakas >> > wrote: >> > >> >> Greetings everybody, >> >> >> >> I issue >> >> mdadm --stop /dev/md0 >> >> and I want to reliably determine that the MD devnode (/dev/md0) i= s gone. >> >> So I look for the udev 'remove' event for that devnode. >> >> However, in some cases even after I see the udev event, I issue >> >> mdadm --detail /dev/md0 >> >> and I get: >> >> mdadm: md device /dev/md0 does not appear to be active >> >> >> >> According to Detail.c, this means that mdadm can successfully do >> >> open("/dev/md0") and receive a valid fd. >> >> But later, when issuing ioctl(fd, GET_ARRAY_INFO) it receives ENO= DEV >> >> from the kernel. >> >> >> >> Can somebody suggest an explanation for this behavior? Is there a >> >> reliable way to know when a MD devnode is gone? >> > >> > run "udevadm settle" after stopping /dev/md0 =A0is most likely to = work. >> > >> > I suspect that udev removes the node *after* you see the 'remove' = event. >> > Sometimes so soon after that you don't see the lag - sometimes a b= it later. >> > >> > NeilBrown >> > >> >> >> >> Thanks, >> >> =A0 Alex. >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe linux-r= aid" in >> >> the body of a message to majordomo@vger.kernel.org >> >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.h= tml >> > >> > >> -- >> 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 =A0http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html