On Thu, Aug 31 2017, Xiao Ni wrote: > ----- Original Message ----- >> From: "NeilBrown" <neilb@xxxxxxxx> >> To: "Xiao Ni" <xni@xxxxxxxxxx> >> Cc: linux-raid@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
