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

[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:
> >
> >> В 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.
> 

"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?

Thanks,
NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131114/9aabce4e/attachment-0001.pgp>