Thank you for looking at both issues, Neil.
Alex.
On Wed, Aug 31, 2011 at 3:54 AM, NeilBrown <neilb@xxxxxxx> wrote:
> On Tue, 30 Aug 2011 18:18:11 +0300 Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
> wrote:
>
>> 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?
>
> I cannot see how it would be md-specific. mdadm doesn't create or remove
> devices when udev is active - it leaves all that to udev.
> If you are curious I suggest you ask the udev developers.
>
>>
>> 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.
>
> It could mean that I had nothing extra to say, but it could also mean that I
> got distracted, forgot, and never got back to it. I live in a world of
> distractions :-(
>
> But a reminder never hurts - it shows that it is important to you, so that
> makes it at least a little bit important to me. I'll go back and have a look
> and see if I have anything useful to add.
>
> NeilBrown
>
>
>>
>> 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
>
>
--
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
