[systemd-devel] Need help with a systemd/mdadm interaction.
Alexander E. Patrakov
patrakov at gmail.com
Wed Nov 13 08:11:27 PST 2013
2013/11/13 NeilBrown <neilb at suse.de>:
> On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov <arvidjaar at gmail.com>
> wrote:
>
>> В Tue, 12 Nov 2013 21:17:19 +1100
>> NeilBrown <neilb at suse.de> пишет:
>>
>> > On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH <gregkh at linuxfoundation.org> wrote:
>> >
>> > > On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
>> > > > On Tue, 12 Nov 2013 00:10:28 -0800 Greg KH <gregkh at linuxfoundation.org> wrote:
>> > > >
>> > > > > On Tue, Nov 12, 2013 at 11:31:45AM +1100, NeilBrown wrote:
>> > > > > > Alternately, is there some "all devices have been probed, nothing new will
>> > > > > > appear unless it is hot-plugged" event. That would be equally useful (and
>> > > > > > probably mirrors what hardware-RAID cards do).
>> > > > >
>> > > > > No, there's no way to ever know this in a hotplug world, sorry.
>> > > > > Especially with USB devices, they show up when they show up, there's no
>> > > > > "oh look, the bus is all scanned now and all devices currently plugged
>> > > > > in are found" type knowledge at all.
>> > > > >
>> > > > > Then there are hotplug PCI systems where people slam in PCI cards
>> > > > > whenever they feel like it (remember, thunderbolt is PCI express...)
>> > > > >
>> > > > > Sorry,
>> > > > >
>> > > > > greg k-h
>> > > >
>> > > > Surely something must be possible.
>> > >
>> > > For USB, nope, there isn't, sorry.
>> > >
>> > > > Clearly a physical hot-plug event will cause more devices to appear, but
>> > > > there must come a point at which no more (non-virtual) devices will appear
>> > > > unless a physical event happens?
>> > >
>> > > Not for USB, sorry.
>> > >
>> > > The USB bus just announces devices when it finds them, there is no "all
>> > > is quiet" type signal or detection.
>> > >
>> > > Same for PCI hotplug, devices can show up at any point in time, you
>> > > never know when, and you don't know when all devices are "found".
>> > >
>> > > sorry,
>> > >
>> > > greg k-h
>> >
>> >
>> > Hmmm... OK. USB doesn't bother me a lot, but PCI is important.
>> >
>> > I guess I'll just have to settle for a timeout much like the current
>> > device-discovery timeout that systemd has.
>> > Still hoping someone can tell me how to plug into that though...
>> >
>>
>> If information about array name or other identification is available in
>> udev rule (I see reference to device node only) what you can do is to
>> start timer with "now+5second" (pick your timeout) that simply fires off
>> mdadm -IRs for specific array. Something like
>>
>> mdadm-last-resort at .timer
>>
>> [Timer]
>> OnCalendar=+5s
>>
>> mdadm-last-resort at .service
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/sbin/mdadm -IRs %n
>>
>> udev rule
>>
>> ... SYSTEMD_WANTS=mdadm-last-resort@$ENV{SOMETHING_UNIQUE}.timer
>>
>
> Thanks. This certainly looks interesting and might be part of a solution.
> However it gets the timeout test backwards.
>
> I don't want to set the timeout when the array starts to appear. I want to
> set the time out when someone wants to use the array.
> If no-one is waiting for the array device, then there is no point forcing it.
>
> That's why I want to plug into the timeout that systemd already has.
>
> Maybe that requirement isn't really necessary though. I'll experiment with
> your approach.
It is useless to even try to plug into the existing systemd timeout,
for a very simple reason. in the setups where your RAID array is not
on the top of the storage device hierarchy, systemd does not know that
it wants your RAID array to appear.
So the statement "If no-one is waiting for the array device, then
there is no point forcing it" is false, because there is no way to
know that no-one is waiting.
--
Alexander E. Patrakov
More information about the systemd-devel
mailing list