| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The raw devices are ready when add event happpens and the raid
can be assembled. So there is no need to handle change events.
And it can cause some inconvenient problems.
For example, the OS is installed on md0(/root) and md1(/home).
md0 and md1 are created on partitions. When it wants to re-install
OS, anaconda can't clear the storage configure. It deletes one
partition and does some jobs. The change event happens. Now
the raid device is assembled again. It can't delete the other
partitions.
So in this patch, we don't handle change event on raw devices
anymore.
Signed-off-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Jes Sorensen <jes@trained-monkey.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
New events have been added in kernel 4.14 ("bind" and "unbind").
Systemd maintainer suggests to modify "add|change" branches.
This patches implements their suggestions. There is no issue yet because
new event types are not used in md.
Please see systemd announcement for details[1].
[1] https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.html
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When adding a device to a container mdadm has to close its file
descriptor before sysfs_add_disk(). This generates change event.
There is race possibility because metadata is already written and other
-I process can place drive differently. As a result device can be added
to two containers simultaneously.
From IMSM perspective there is no need to react for change event. IMSM
doesn't support stacked devices.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
${DEVLINKS}
is not valid udev syntax, and is passed through uninterpreted.
$env{DEVLINKS}
or
%e{DEVLINKS}
is correct.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a device isn't fully initialized (e.g if it should be
handled by multipathing) it should not be considered for
md/RAID auto-assembly. Doing so can cause incorrect results
such as causing multipath to fail during startup.
There is a convention that the udev environment variable
SYSTEMD_READY be set to zero for such devices. So change
the mdadm rules to ignore devices with SYSTEMD_READY==0.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
|
| |
|
|
|
|
|
|
| |
Every place where the paths for mdadm or mdmon is explicit,
it should use the BINDIR setting, not "/sbin/".
Reported-by: member graysky <graysky@archlinux.us> (https://bugs.archlinux.org/task/37330)
Signed-off-by: NeilBrown <neilb@suse.de>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--incremental currently fails if the device name passed does not
textually match the names permitted by the DEVICE line in mdadm.conf.
This is problematic when "mdadm -I" is run by udev as the name given
can be a temp name.
This patch makes two improvements:
1/ We generate a list of all existing devices that match the names
in mdadm.conf, and allow rdev based matching
2/ We allows extra aliases to be provided on the command line, and
perform textual matching on those. This is particularly suitable
for udev usages as ${DEVLINKS} can be provided even though the links
make not yet be created.
Signed-off-by: NeilBrown <neilb@suse.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally "mdadm -I" will not start an array if it has reason to
expect further devices.
This means that if a device is removed while the host is shut down,
"mdadm -I" will never start the device.
If the array is know to the host, it make sense to start the array
anyway after a reasonable timeout.
This patch adds systemd/udev infrastructure so that 30 seconds after
a known array first becomes able to be assembled as a degraded array,
the array will be assembled even if more devices are still expected.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
Right now, the rules that run blkid on raid arrays are executed after
the assembly rules. This means incremental assembly will always fail
when raid arrays are again physical components of raid arrays.
Instead of simply reversing the order, split the rules up into two files,
one dealing with array properties and one dealing with assembly.
Signed-off-by: NeilBrown <neilb@suse.de>
|
