On 09/19/2017 02:49 AM, NeilBrown wrote:
On Tue, Sep 19 2017, Xiao Ni wrote:
After mdadm -S /dev/md0, the device node /dev/md0 still exists. The Remove
events are generated by md_free() -> del_gendisk() -> blk_unregister_queue().
After calling close(mdfd) the Remove events is generated. We should give udev
a little time to handle the event.
I tried usleep(100*1000), but the problem still can be reproduced sometime.
So I choose to sleep(1). Because after close(mdfd) it can be generated CHANGE
events too. So it's ok to choose to sleep(1) to wait udev to handle CHANGE
events.
I really don't like this approach. The fact that 1 second works for you
is no guarantee that it will work for everybody.
We have a few sleeps in the code already, but I don't like them either.
Let's try not to add more.
If there is some event that you want to wait for, wait for that event.
e.g. if you want to wait for /dev/md0 to disappear then write a loop:
while /dev/md0 exists
usleep(1000)
But I'm still not convinced that this is really needed. If it is, then
maybe some sort of kernel fix would be better.
I agree completely - any case where we need a sleep() is a warning that
there is probably a bigger problem that needs to be addressed.
Cheers,
Jes
--
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
