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>
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>
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>
'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>
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>
A previous patch moved move the '--examine --brief' reporting of
member arrays to before their containers. This breaks "mdadm -As"
assembly. So put them back, but still fix the problem addressed by
previous patch.
Signed-off-by: NeilBrown <neilb@suse.de>
imsm spares do not have container membership by default so we associate
them with the first container found in the configuration file. Some
ARRAY lines do not specify the metadata type so we cannot assume that
_cst will always be valid.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The family_number field can change. The option-rom will change the
family number when it starts a rebuild process (flags a container for
rebuild). This was not seen previously as mdadm would usually start the
rebuild process, preserving the family number.
This is the mechanism that helps to prevent a prodigal array member from
being returned to its original system and cause a rebuild to go in the
wrong direction. With the change we will end up with a container that
will fail to assemble unless the device with the incompatible family
number is left out of the assembly.
So, take several actions:
1/ Convert uuid generation to use orig_family_num, being careful to
preserve the existing uuid in the case where orig_family_num is not
set (i.e. previous mdadm created imsm arrays)
2/ Set orig_family_num at Create. For arrays created by mdadm prior to
this release orig_family_num will be zero, so set it to family_num at
the first metadata write.
3/ Add checks for orig_family_num to compare_super_imsm
4/ Update the family number when initiating rebuild
5/ The option-rom mixes some random data into the family number, add
this functionality to the mdadm implementation.
Reported-by: Marcin Labun <marcin.labun@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The last sector of an array is calculated by start + size - 1.
Reported-by: Rafal Marszewski <rafal.marszewski@intel.com>
Reported-by: Jarema Bielanski <jarema.bielanski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The map file needs to be updated after adding the first member array to
an Intel metadata container. The uuid for an imsm container uses the
->family_num field of the metadata. This field is static, but is only
set after the first member array has been created. Prior to this all
devices are free floating spares and do not have any information that
can identify specific container membership. At Create() time we take
the uninitialized uuid from ->get_info_super() prior to updating the
metadata. So the current result is:
# mdadm --create /dev/md/imsm /dev/sd[b-e] -n 4 -e imsm
# mdadm --create /dev/md/vol0 /dev/md/imsm -n 4 -l 0
# cat /var/run/mdadm/map
md126 /md127/0 3e03aee2:78c3c593:1e8ecaf0:eefb53ed /dev/md/vol0
md127 imsm 53d6f8b1:7a783f24:f30483c5:705c48c7 /dev/md/imsm
# mdadm -Ebs
ARRAY metadata=imsm UUID=589d2d2c:4221a54d:acb63c06:c3907f52
ARRAY /dev/md/vol0 container=589d2d2c:4221a54d:acb63c06:c3907f52
member=0 UUID=57b89b63:5cd0eae1:17dd26b3:51cc78d4
So, before we write out the new metadata check to see if the member
array uuid has changed as a result of this addition. If it has, update
its uuid in the map file and flag its parent container for updating. In
support of updating the container uuid the semantics of
->write_init_super are changed to clear any metadata specific member
array cursors (e.g. ddf_super.currentconf or intel_super.current_vol)
such that a subsequent call to ->getinfo_super returns container
information.
Reported-by: Ignacy Kasperowicz <ignacy.kasperowicz@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Prior to creating any arrays in a new container the output from -Ebs for
a 4-disk imsm array returns:
spares=4
We should at least display that these are imsm spares:
ARRAY metadata=imsm
spares=4
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When performing an "-Ebs -e <metadata type>" we segfault because the
superblock has been freed too early. We also leak memory for 'ddf' and
'imsm' because, unlike super[01], we do not implicitly free when
->load_super is called on an already loaded supertype.
So, fix up imsm and ddf to match type 0 and 1 ->load_super() semantics,
and update Examine to not free the superblock until all usages have been
exhausted.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
RebuildMap wants to poll through mdstat and retrieve a (kernel name,
uuid, user name) tuple for each array. Teach imsm and ddf to honor
st->sub_array at ->load_super() time to set their internal subarray
pointers to the value specified in st->subarray, or return an error if
st->subarray specifies an invalid array.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
With --verbose, --examine --brief prints dev= information after
the personality has done its bit.
But with containers, the member array are printed in between.
So in super-ddf and super-intel, move printing of the member
arrays to before printing of the container. This avoids
confusion.
Signed-off-by: NeilBrown <neilb@suse.de>
We sometimes set failed_disk_num to ~0.
However we cannot test for equality with that as failed_disk_num
is 8bit and ~0 is probably 32bit with lots of 1's.
So test if ~failed_disk_num is 0 instead.
Reported-By: "Mr. James W. Laferriere" <babydr@baby-dragons.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The auto parameter is obsolete after kernel version 2.6.28 as all arrays
are partitionable via block device extended minor support. Environments
that requre the mdp style of array can always edit the configuration
file to specify auto=mdp.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The 'num_domains' field simply identifies the number of mirrors. So it
is 2 for a 2-disk raid1 or a 4-disk raid10. The orom does not currently
support more than 2 mirrors, but a three disk raid1 for example would
increase num_domains to 3.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
It always afters to cast big things to (unsigned long long) before
printing as %llu - it seems there will always be one arch which
has something to complain about ....
Signed-off-by: NeilBrown <neilb@suse.de>
Because ---examine --brief, or --detail --brief are
often used to create mdadm.conf, and because people don't want to
have to update their mdadm.conf unnecessarily, we don't want to
include information that might change.
And now that level changing is supported, that is almost everything
but UUID.
So move some more fields into the "Only print with --verbose" class.
Signed-off-by: NeilBrown <neilb@suse.de>
imsm arrays round down the effective array size to the closest 1
megabyte boundary so teach get_info_super_imsm and sysfs_set_array to
set 'md/array_size' if available (and make sure ddf uses the default
size).
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
New documentation shows that this field is not equivalent to
md/resync_start. Disable updates until full support can be developed.
Writing '0' when a migration starts/re-starts remains correct.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Until support for higher order migrations (online capacity expansion,
raid level migration, chunk size migration...) are implemented do not
allow arrays in these states to be assembled.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
imsm distinguishes parity initialization from parity checking in the
metadata. Older option roms marked the repair operation with the
'verify' type and a 'with fixup' flag in the raid device 'status' field.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
'num_domains' is the number of parity domains. I.e. 2 in the raid10
case (2-mirrors), while raid0 through raid5 have 1 parity domain (even
though raid0 does not have parity).
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
According to new documentation the metadata expects that all whitespace
(characters <= 0x20) are stripped from the incoming serial number. If
the length remains longer than MAX_RAID_SERIAL_LEN then only the
right-most characters are preserved.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
In support of auto-layout:
1/ collect and merge all extents to find the largest common-start free region
2/ verify that we meet the "all volumes must use the same set of disks"
2/ mark the disks to be added in add_to_super_imsm_volume
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
All operations that rely on loading from an existing container (like
--add) will fail after a disk has been removed. Provide an option to
skip missing / offline disks rather than abort. We attempt to do this
in the load_super_{imsm,ddf}_all cases when mdmon is running i.e. we
already have a consitent version of the metadata running in the system.
Otherwise, we fail as normal and let the administrator fix up the
container.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If the checksum verification fails and mdmon is running we retry the
load to get a consistent snapshot of the mpb. Found by
tests/08imsm-overlap.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Actually, rename mark_failure to mark_missing and then implement the
correct mark_failure which according to new documentation is to:
1/ Set the FAILED status bit
2/ Set IMSM_ORD_REBUILD to mark the disk out of sync
3/ Set map->failed_disk_num if this is the first failure detected
failure (it is ~0 otherwise)
Previously the assumption was that IMSM_ORD_REBUILD only appeared in
map[1], so all routines that care about out-of-sync disks need to be
updated.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
A foreign disk is one that all other drives believe is not-in-sync but
does not have the 'failed' status bit set.
This also reverts, because that commit is addressing the wrong problem.
Ideally mdmon would kick "non-fresh" drives like the kernel does at
native-md activation time, but that is too awkward to implement at the
moment because mdadm owns container manipulations.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Spares in the imsm case are marked with the "match-all" uuid of
ffffffff-ffffffff-ffffffff-ffffffff. When performing incremental
assembly we need to associate such devices with a populated container
uuid. Also when performing --detail on a container with only spares
present we can make an attempt to return a real uuid.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
IMSM_NO_PLATFORM turns off checks that should be tested, so provide a
IMSM_TEST_OROM variable to allow testing the orom constraints in the
mdadm regression suite.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
mdadm -C /dev/md/r1d2n1s0-5 -amd -l1 --size 5242880 -n 2 /dev/sdb /dev/sdc -R -f -v -c 64
mdadm: chunk size ignored for this level
mdadm: super0.90 cannot open /dev/sdb: Device or resource busy
mdadm: super1.x cannot open /dev/sdb: Device or resource busy
mdadm: platform does not support a chunk size of: 0
mdadm: device /dev/sdb not suitable for any style of array
Reported-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
Tested-by: Jacek Danecki <jacek.danecki@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Failed disks do not have valid serial numbers which means we will not
pick up the 'failed' status bit from the metadata entry. Check for
dl->index == -2 to prevent failed disks from being incorporated into the
container.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If the metadata handler can not find its platform support components
then there is no way for it to verify that the raid configuration will
be supported by the option-rom. Provide a generic method for metadata
handlers to warn the user that the array they are about to create may
not work as intended with a given platform.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This is a key orom-compatibility constraint. A nice side effect is that
it precludes the corner case of 'create' racing against 'spare activate'
since the create will fail to convert a spare into an array member. At
create time we check if this is the first member array in the container
if it is than all disks are possible candidates, if it is not then only
current members are permitted.
A bit hairier is spare-activation handling in the presence of this
constraint. It is difficult because spare handling is per array. The
approach taken is to:
1/ check that a new spare can cover all defined arrays in the container
2/ ensure that partially assimilated spares are the first candidates
when looking for a spare region to activate.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Let handlers specifiy their own defaults, specifically needed for the
imsm-raid5 case where mdadm defaults to 'ls' and imsm to 'la'.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dump the orom capabilities and hardware disk configuration. This code
relies on the name of scsi_host objects to determine the hardware port
number. Hopefully this information is stable...
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Metadata formats like imsm work in concert with platform firmware and
hardware, so provide a way for mdadm to display this info to the user.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
These checks are only enabled when platform support for imsm is found,
i.e. ahci driver is loaded and talking to an Intel(R) controller, and
the option rom header is located.
They can be turned off by setting the environment variable
IMSM_NO_PLATFORM to 1.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
imsm metadata requires all members of a raid volume to start at the same
offset. So, incrementally build a composite disk from all the
candidates passed to ->validate_geometry. After each disk is added
merge the extents and search for a common start offset that satisfies
the requested raid device size.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When chunksize is 0 in the raid1 case we need to use
info_to_blocks_per_member() to calculate the array size.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If, when creating an array, a signal target device is given which
is a container, then allow the metadata handler to choose which
devices to use.
This is currently only supported for DDF.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ When truncating the space reserved for the metadata round down to an
even numbered sector count to avoid an off-by-one error when
sysfs_add_disk rounds up.
2/ Set the current metadata parameter block size
as a floor.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Make sure every failure from add_to_super prints a suitable
error message, and then don't print any error in the caller.
Signed-off-by: NeilBrown <neilb@suse.de>
Change the multibyte disk status field definitions to imsm byte-order
(little-endian) to match other multibyte field definitions.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Change the "env_check_mdmon" function to be more generic, accepting
and environment variable name, as soon we will have a new use for it.
Signed-off-by: NeilBrown <neilb@suse.de>
If a spare is included in the list of examined disks we need to copy in at
least enough information to get the uuid of the populated container.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This prevents a uuid of all f's from being displayed when an imsm spare is
listed along with active disks for mdadm -Eb.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Examine() is actually looking at the ACTIVE bit. This happened to work for
imsm spares but now it needs to be fixed up.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Raid disk and disk number information is not relevant at the container
level, especially for imsm. So arrange for getinfo_super_imsm() to
always publish devices as spares and report the number of spares at
Assemble() time.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The uuid returned for an imsm spare device will never match the uuid of an
active disk. So make mdadm interpret a uuid of all f's as "match any".
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Both super-ddf and super-intel ignore memory allocation failures during
->activate_spare. Fix these up by cancelling the activation.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
load_imsm_disk() currently notices if spares missed their activation
update, but we allow a stale failed disk back in to the array because its
serial number is clobbered in the most up-to-date disk.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If a drive is removed while mdmon is not running we need a way to
identify what is missing and mark that disk as failed in the metadata.
At ->load_super() time create a list of missing disks defined as a disk
that is marked in-sync yet does not appear in super->disks.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Spotted a thinko... raid devices are dynamically sized, disks are not.
The space for disks is always mpb->num_disks * sizeof(struct imsm_disk).
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
When the array is shutdown, or when mdadm --wait-clean is called, any
active resync process will be idled allowing mdmon to record the current
resync position.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
md/resync_start reports different terminal values depending on kernel
configuration (~0UL versus ~0ULL). Make detection of the
resync-complete state more robust by comparing against array size.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
On ich6r the option-rom appears to reserve only 432 sectors rather than
the 418+4096 of newer implementations. For compatibility trust the
metadata in these cases.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
1/ near-2 indeed matches how the Windows driver lays out the data
2/ update imsm_check_degraded to check for rebuilding disks in the
raid10 case
Signed-off-by: Dan Williams <dan.j.williams@intel.com>