From mboxrd@z Thu Jan 1 00:00:00 1970 From: NeilBrown Subject: Re: The dev node can't be released at once after stopping raid Date: Fri, 01 Sep 2017 09:39:21 +1000 Message-ID: <87wp5je28m.fsf@notabene.neil.brown.name> References: <1159964415.16461871.1496288839399.JavaMail.zimbra@redhat.com> <43bca632-9d77-2063-603c-6dcf47f3d250@suse.com> <1471667815.16472496.1496296238179.JavaMail.zimbra@redhat.com> <1941784023.3852671.1504151717389.JavaMail.zimbra@redhat.com> <87bmmwfj5z.fsf@notabene.neil.brown.name> <1889255088.3872827.1504160273377.JavaMail.zimbra@redhat.com> <8760d4fd25.fsf@notabene.neil.brown.name> <716638049.3884368.1504163810231.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: In-Reply-To: <716638049.3884368.1504163810231.JavaMail.zimbra@redhat.com> Sender: linux-raid-owner@vger.kernel.org To: Xiao Ni Cc: linux-raid@vger.kernel.org List-Id: linux-raid.ids --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 31 2017, Xiao Ni wrote: > ----- Original Message ----- >> From: "NeilBrown" >> To: "Xiao Ni" >> Cc: linux-raid@vger.kernel.org >> Sent: Thursday, August 31, 2017 2:48:02 PM >> Subject: Re: The dev node can't be released at once after stopping raid >>=20 >> On Thu, Aug 31 2017, Xiao Ni wrote: >> > >> > There is a bug https://bugzilla.redhat.com/show_bug.cgi?id=3D1444434. >> > Another tool(blivet) stops raid device and the device node still exist= s. >> > Then it calls mdadm -S xxx again and it fails. >>=20 >> I would suggest that the tool is broken. It should trust mdadm and not >> double check that it actually worked. >>=20 >> > So I ask myself why >> > /dev/mdxxx can't be removed immediately after command mdadm -S. >>=20 >> Because udev is asynchronous. You cannot rely on things happening >> instantly. udev doesn't work that way. >>=20 >> mdadm has a function 'wait_for()' which waits for the device name to >> appear when the array is started. Possibly we could add something to >> wait for udev to remove the device when the array is stopped, but I >> really think it shouldn't be necessary. Nothing should look at the name >> after the device is stopped. > > Hmm I want to try it. There are many topics about /dev/mdxx exists after > stop array before. I want to stop this topic forever.=20 > > Can we remove /dev/mdxx directly? Something like this: > diff --git a/Manage.c b/Manage.c > index b82a729..04994b3 100644 > --- a/Manage.c > +++ b/Manage.c > @@ -482,6 +482,7 @@ done: > map_lock(&map); > map_remove(&map, devnm); > map_unlock(&map); > + unlink(devname); udev will create the device and multiple links. You are just removing the device. Someone might come along and complain about the links. I don't like this change. NeilBrown > out: > sysfs_free(mdi); > > > Best Regards > Xiao=20 > >>=20 >> > >> > In topic "MD Remnants After =E2=80=93stop", you said the REMOVE events= are >> > generated by "md_free() -> del_gendisk() -> blk_unregister_queue()". >> > When mdadm -S return, the REMOVE events should be generated already, >> > right? >>=20 >> Not necessarily. md_free is called from mddev_delayed_delete, which is >> run on a work-queue, so might be delayed briefly. >>=20 >> > >> > I always have a question. Who is responsible for removing the device >> > node under /dev/ directory? The function unlink()? >>=20 >> udev is responsible for removing the device. Obviously udev uses unlink= () >> to do this. >>=20 >> NeilBrown >>=20 >>=20 > -- > 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlmonisACgkQOeye3VZi gbnNIg/9HyFxXJobm6FW6IDy/Ds0EfWeVtGvzecc3Z6MHmOh3cIdk1WHPlS1eC36 i0U2jgP0DSVWPuVe6gkXvnU5+zb4u5HDVCgitn3Lr0EFVnaUbZjmJbg/gBwLoV0Z Cb+8U3/8AgCBitZlNNF6uZkgvVblSUgI+npknxOmX4hdx1SNqaQV4M3Z7ucoG+h4 ORBtKjhty5LJFmr0fBchkdUXmUBDwVLxhgRxLx+74NwPmhJ2zRg2pRFQ44XfgRgF RFPEs6RiRAY3cIh5Cvshr1WtOhrHpByzQMqDUf23IciDOO3Dr4QqZMa85cIoTaiB Tr0HtGt2c5eJtZzy2RxZBMQ07cK8fZHk1iRcglN7UW9s5wQdTQYQP3G/G9daWg1P mRQJgpE7wg/ctpW4P92T88U3FARZPDV2p5W+URLzAs+NwEUpH4Hg67IUg78L1l6v mCOxJD0acblsBzpGV6+mGHdu/fmrX+B6s0NJ6xp9WjgJ3C5j3otejgEWFuptxo9y ka8EKCk2gJXQt+QuYRm9btbQiyMQoXsTavn4+mmWljXoavZuYdRIc7dSivCJpgKR pVF7p7a7tfVTr6FwGjkAU61lhRhEfqDMsXxMeaIlL2aGgMcSW9sdQ3+F0Srs0ds9 05551NVmr425IKnE+mPiFLyEvb15FIE8p/2BvM9aSL7tpdaQKTA= =1ca9 -----END PGP SIGNATURE----- --=-=-=--