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. > > 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
Attachment:
signature.asc
Description: PGP signature
