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: Friday, September 1, 2017 7:39:21 AM
> Subject: Re: The dev node can't be released at once after stopping raid
> 
> On Thu, Aug 31 2017, Xiao Ni wrote:
> 
> > ----- 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);
> 
> udev will create the device and multiple links.  You are just removing
> the device.  Someone might come along and complain about the links.

Sorry, could you explain "udev will create the device and multiple links" in detail? 
Does it mean unlink can cause udev to re-create the device and multiple links? Or
You mean it should remove other links by unlink too, not only the device?

Regards
Xiao
> 
> I don't like this change.
> 
> NeilBrown
> 
> 
> >  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
> >> 
> >> 
> > --
> > 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
>