Two small fixes related to enough()

1/ enough_fd doesn't use avail_disks any more, so discard it.

2/ Manage_Add increments 'found' at the wrong place, so it can
   waste time before calling enough().

Signed-off-by: NeilBrown <neilb@suse.de>
Assemble/Incremental: don't hold O_EXCL on mddev after assembly.

As soon as the array is assembled, udev or systemd might run
fsck and mount it.  So we need to drop O_EXCL promptly.

Signed-off-by: NeilBrown <neilb@suse.de>
Add mdmonitor.service systemd unit file.

This systemd unit file runs mdadm in --monitor mode.
It is started by a SYSTEMD_WANTS signal from udev whenever
an md array is started that would benefit from mdadm --monitor.

Commandline arguments can be provided by a script
  /usr/lib/systemd/scripts/mdadm_env.sh
which should write an
  MDADM_MONITOR_ARGS=....
line to /run/sysconfig/mdadm

A script to extra args from SUSE's /etc/sysconfig/mdadm file
is provided.
If no mdadm_env.sh is provided, then args are "--scan" which
requires "mail" or "program" to be set in /etc/mdadm.conf.
I believe this is suitable for Fedora.

Signed-off-by: NeilBrown <neilb@suse.de>
udev rules: add some by-pass rules from Fedora

1/ If ANACONDA is running, don't -I assemble any arrays, ANACONDA
   needs to be in control
2/ honour "noiswmd" and "nodmraid" kernel command line options.

Signed-off-by: NeilBrown <neilb@suse.de>
udev rules: try "mdadm -I" on "change" events.

We need to attempt "mdadm -I" on "change" events as well as "add" events,
as the "change" make make a device ready to be part of an array.
This is particularly important for stacked md devices. When the
member devices are "add"ed they don't have any content visible yet.
That doesn't happen until a "change".

Idea taken from Fedora udev file.

Signed-off-by: NeilBrown <neilb@suse.de>
mdamd-last-resort: add a Conflicts line to stop the timer.

When the md device actually appears we want to stop the timer and not
bother with the mdadm-last-resort@.server.  In particular, running
that causes confusing messages and is in general best avoided.

Fortuantely this can simply be achieved with a Conflicts= line

Signed-off-by: NeilBrown <neilb@suse.de>
Clarify scope of Rebuild events in mdadm manpage

To date, the manpage did not make it clear under which circumstances
Rebuild events are generated, leading to a question on the mailing
list as to whether it is normal for these events to be generated
while checking an array.
So clarify that all operations that act on the entire array are in
scope. The list is given as "e.g.", because it might grow in the
future as other full-array operations are added.

Reported-by: Mark Knecht <markknecht@gmail.com>
Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
Signed-off-by: NeilBrown <neilb@suse.de>