Re: The dev node can't be released at once after stopping raid

[Xiao Ni <xni@redhat.com>]

----- Original Message -----
> From: "NeilBrown" <neilb@suse.com>
> To: "Xiao Ni" <xni@redhat.com>
> 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
> 
> On Thu, Aug 31 2017, Xiao Ni wrote:
> >
> > There is a bug https://bugzilla.redhat.com/show_bug.cgi?id=1444434.
> > 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.
> 
> 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.

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. 

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);
 out:
        sysfs_free(mdi);


Best Regards
Xiao 

> 
> >
> > In topic "MD Remnants After –stop", 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?
> 
> 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
> 
>