[systemd-devel] Need help with a systemd/mdadm interaction.

[Alexander E. Patrakov]

NeilBrown пишет:
> On Wed, 13 Nov 2013 22:11:27 +0600 "Alexander E. Patrakov"
> <patrakov at gmail.com> wrote:
>
>> 2013/11/13 NeilBrown <neilb at suse.de>:
>>> On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov <arvidjaar at gmail.com>
>>> wrote:
>>>
>>>> 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.
>>
> "useless" seems a bit harsh.  "not-optimal" may be true.
>
> If systemd was waiting for a device, then it is clear that something was
> waiting for something.  In this case it might be justified to activate as
> much as possible in the hope that the important things will get activated.
> This is what "mdadm -IRs" does.  It activates all arrays that are still
> inactive but have enough devices to become active (though degraded).  It
> isn't selective.
> If they are deep in some hierarchy, then udev will pull it all together and
> the root device will appear.
>
> If systemd is not waiting for a device, then there is no justification for
> prematurely starting degraded arrays.
>
>
> Maybe I could get emergency.service to run "mdadm -IRs" and if that actually
> started anything, then to somehow restart local-fs.target.  Might that be
> possible?

If this is the way forward, then we, obviously, should think about a 
general mechanism that is useful not only for mdadm, but also to other 
layered storage implementations such as dm-raid, or maybe multi-device 
btrfs, and that is useful if more than one of these technologies are 
used on top of each other. This by necessity leads to multiple emergency 
missing-device handlers. And then a question immediately appears, in 
which order the emergency handlers should be tried, because all that is 
known at the time of emergency is that some device listed in /etc/fstab 
is missing. I suspect that the answer is "in arbitrary order" or even 
"in parallel", but then there is a chance that one run of all of them 
will not be enough.

This is not a criticism, just something to be fully thought out before 
starting an implementation.

-- 
Alexander E. Patrakov