Thanks, Neil.
Although according to udev documentation: "the udev events are sent
out after udev has finished its event processing, all rules have been
processed, and needed device nodes are created."
Also looking at udev-worker code of udevd, the
udev_monitor_send_device() call is done after all the rules have been
processed.
Nevertheless, I looked at udevadm_settle.c and did some equivalent of
that in my code, and it looks like the issue is resolved. Perhaps
there is something md-specific here?
Another thing, since you are reading this thread, I wanted to ask
whether you have any advice on the "RAID5: failing an active component
during spare rebuild - arrays hangs" thread I opened some time ago.
Since you were not answering, I assume there is nothing additional you
can advise about, correct? I apologize if this off-topic was
inappropriate.
Thanks for the help,
Alex.
On Tue, Aug 30, 2011 at 12:25 AM, NeilBrown <neilb@xxxxxxx> wrote:
> On Mon, 29 Aug 2011 20:17:34 +0300 Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
> wrote:
>
>> Greetings everybody,
>>
>> I issue
>> mdadm --stop /dev/md0
>> and I want to reliably determine that the MD devnode (/dev/md0) is gone.
>> So I look for the udev 'remove' event for that devnode.
>> However, in some cases even after I see the udev event, I issue
>> mdadm --detail /dev/md0
>> and I get:
>> mdadm: md device /dev/md0 does not appear to be active
>>
>> According to Detail.c, this means that mdadm can successfully do
>> open("/dev/md0") and receive a valid fd.
>> But later, when issuing ioctl(fd, GET_ARRAY_INFO) it receives ENODEV
>> from the kernel.
>>
>> Can somebody suggest an explanation for this behavior? Is there a
>> reliable way to know when a MD devnode is gone?
>
> run "udevadm settle" after stopping /dev/md0 is most likely to work.
>
> I suspect that udev removes the node *after* you see the 'remove' event.
> Sometimes so soon after that you don't see the lag - sometimes a bit later.
>
> NeilBrown
>
>>
>> Thanks,
>> Alex.
>> --
>> 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
>
>
--
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
