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: Thu, 31 Aug 2017 16:48:02 +1000 Message-ID: <8760d4fd25.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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: In-Reply-To: <1889255088.3872827.1504160273377.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: > > There is a bug https://bugzilla.redhat.com/show_bug.cgi?id=3D1444434.=20 > Another tool(blivet) stops raid device and the device node still exists. > Then it calls mdadm -S xxx again and it fails. I would suggest that the tool is broken. It should trust mdadm and not double check that it actually worked. > 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. 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. > > In topic "MD Remnants After =E2=80=93stop", you said the REMOVE events ar= e=20 > generated by "md_free() -> del_gendisk() -> blk_unregister_queue()". > When mdadm -S return, the REMOVE events should be generated already, > right? Not necessarily. md_free is called from mddev_delayed_delete, which is run on a work-queue, so might be delayed briefly. > > I always have a question. Who is responsible for removing the device > node under /dev/ directory? The function unlink()? udev is responsible for removing the device. Obviously udev uses unlink() to do this. NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlmnsSQACgkQOeye3VZi gbmm9g//fEoDyfurVedO73pleqN+8ooz5IAnUEmsQ46T3Jm6tHTb4/3L4EdthUEq dkZOUsxcjs8nR4O+G8C/KKc6HI3+LzJHGjiDgJpjyYG2jFNvE/4DILum740JvVak QkAo+T+E4gNiBKPVy0KOPCTXDbJl9hqLYiz40RwmFnXNMRyCkDzB4fQimXOP+5XG ta/tlnHj0dATsu3iLOmKtXOQjvIGStntdiRLXA7B0ZMpISfQsNpk1IRyqtk89PAF Xd4WPvWRxm27zSLaG2gf0D7Okd8kGWeey5lpfJZAChJlMIce8NS//VUjl3iKSZ/6 yXR84R4D4CFg0eMMcN/65+pprAZNibKbLLtNtag83vzCFE0t3hxX4HJf9SKTk8sy lRH0oPumdNO/NL6zsqLr0aCUx8mcGkQpssZT7oUXlFmo2C4ksgQIbuO5g/HTXgU0 3B7YvwNlowX7D2ndbaEsyp+1dd8CE3dHRaBlpo8GKpdnTePGMlcA/UCY0qjE4T97 4piMUrUq/erSIkME+QEV9Ndd6oCEIFHTEoBRrGUk58p9YzZvAOo0ce5KBE+KYxgA QV7fbTZOSTIAEjXyHK5nY7J4v5ujX1QxS0lbC4xii5xW4aAVrlIfmTAzTNuVD73t Nnx4fZ54KJo8QoWhA1Wm2bqAuCHtmHl4XVDs0YukiQdGuH7T7jo= =nzTg -----END PGP SIGNATURE----- --=-=-=--