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

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]