I think we sometime get way ahead of udev and devices disappear
and appear almost at random. So add some settling.
Signed-off-by: NeilBrown <neilb@suse.de>
ie. the percent increments after which RebuildNN event is generated
This is particulary useful when using --program option, rather than
(only) syslog for alerts.
Signed-off-by: Zdenek Behan <rain@matfyz.cz>
Signed-off-by: NeilBrown <neilb@suse.de>
mlockall(MCL_FUTURE) only locks mappings that have not yet
been created. To lock all memory used by the process, we need
MCL_CURRENT | MCL_FUTURE
Signed-off-by: NeilBrown <neilb@suse.de>
FIXME this is wrong . what direction does reshape_position move?
If the device count in an array is shrinking, the critical
region is different so the tests need to be different when
restarting.
Signed-off-by: NeilBrown <neilb@suse.de>
On small (test) arrays, multiplying by 16 can make the 'chunk' size
larger than half the array, which is a problem.
Signed-off-by: NeilBrown <neilb@suse.de>
Connect to the monitor in the old namespace and use that connection for
WaitClean requests when stopping the victim mdmon instance. This allows
ping_monitor() to work post chroot().
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Try to execute mdmon from the target namespace. When used for initramfs
handovers we need to drop all references to the initramfs filesystem for
that memory to be freed.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When killing a previous monitor be careful not to cause writes to the
filesystem until the reads necessary to get the monitor operational have
completed.
The code is already prepared for errors creating the pid and socket
files, so simply defer creation of these files until after the first
call to manage().
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The load_super() from an mdadm --detail call may race against an mdmon
update. When this happens the load_super sees an inconsistent metadata
block and returns an error. The fallback path to use the map file
contents lacks uuid reporting, so provide __fname_from_uuid for
generically printing a uuid.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Provide a test to sanity check assembly and reassembly in the presence
of conflicting family number information.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When disks have conflicting container memberships (same container ids
but incompatible member arrays) --update=uuid can be used to move
offenders to a new container id by changing 'orig_family_num'.
Note that this only supports random updates of the uuid as the actual
uuid is synthesized. We also need to communicate the new
'orig_family_num' value to all disks involved in the update. A new
field 'update_private' is added to struct mdinfo to allow this
information to be transmitted.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The full fix would be to support updating ddf metadata, but this minimal
fix just prevents the superblock from being zeroed when someone
inadvertently passes an unsupported --update option during assembly.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Fix init_super_imsm() to return an empty mpb when info == NULL, and
teach store_super_imsm() to simply write out the passed in mpb.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=523320
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
imsm_activate_spare() in the manager thread may race against
write_super_imsm_spares() in the monitor thread. Give
write_super_imsm_spares() its own private mpb buffer to prevent
confusing the manager.
This change uncovered cases where spares were not being assembled due to
a failed metadata version number check. Spares can freely associate
across metadata version number, so reduce the scope of the version check
in the spare assembly case.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The last time wait_backup is called, it might see reshape
finish and so return an error indicator.
But this is not an error, and we must go ahead and prepare
the array for full access.
Signed-off-by: NeilBrown <neilb@suse.de>
This is a result of trawling through the Windows implementation to learn
the mechanism of how it disambiguates family_num. It is a continuation
of commit 148acb7b "imsm: fix family number handling" which introduced a
regression when reassembling a container with stale disks and rebuilt
members.
When rebuilding, a new family number is assigned to protect against the
"prodigal array member" problem. It prevents a former family member
from returning to the system and causing a rebuild to go the wrong
direction. However, this invalidates looking at the generation number to
determine the most up-to-date disk when comparing across family numbers.
Instead the assembly logic looks for agreement between a disk's local
family membership compared against a global list of all families in the
system. Whenever a disk's local metadata does not match a family number
on the global list that family number is marked offline.
It is possible that this logic results in multiple incompatible but
valid family numbers existing in a container. In this case mdadm.conf
cannot be consulted because it only records the uuid which is generated
from static fields in the metadata. The metadata lacks the data needed
to disambiguate "local" versus "foreign". The "foreign" array in this
case requires updating to change its container-id information
(orig_family_num), and possibly the member array names.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
None of the other formats close the passed in fd at load, and this
becomes a problem when trying to support --update where we need O_EXCL
protection across the entire operation.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If homehost is not set - typically during early boot,
and assemble of v0.90 metadata arrays will crash.
Reported-by: Paweł Sikora <pluto@agmk.net>
Signed-off-by: NeilBrown <neilb@suse.de>
mdmon was creating a supertype struct with malloc, and thus not
necessarily getting zero-d memory.
This was causing it to segfault when called like this from the initrd:
/sbin/mdmon /proc/mdstat /sysroot
The problem was that load_super_imsm would get called on the non-zero'd
super struct, whcih in turn calls free_super_imsm, which checks st->sb,
which should be zero but isn't and then starts freeing bogus memory.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
'USABLE_DISK' is not a 'persistent' status flag it is an internal status
flag used for the in memory representation of the disk in the Windows
driver.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
mdadm -Ebs will include containers in the scanned device list.
Examine() falsely thinks they are spares when MD_DISK_SYNC is not set.
This could be fixed by forcing all formats to set this flag for
container devices, but this flag is currently used by imsm to identify
free-floating spares.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Spares for imsm arrays do not have any info about the container in their
metadata records. If Detail() inadvertantly picks such a device for
->get_array_info() it will end up with less than useful info for the
container. So, continue to read from the disks until a non-spare device
is found.
This bug was found by timeouts waiting for udev to create the
user-friendly container name. To detect future UUID reporting problems
and a debug print to the timeout case in wait_for().
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If we dump any 'spare' or 'device' information for a container in the
'brief' case then we need a newline before printing member array info.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
1/ Fix an off by one error when detecting whether the device allocation
loop succeeded or not
2/ Update ->num_raid_devs before copying to avoid a segmentation fault
Signed-off-by: Dan Williams <dan.j.williams@intel.com>