Check for supportable secondary RAID configurations.
There is currently only one: RAID 10, if the stripe
sizes and Basic volume sizes are all equal.
With this patch, mdadm will not try to start unsupported
secondary RAID level configurations any more.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
When searching for container elements, loop over the known phys
disks rather than the elements of the current configuration.
This patch changes nothing in the logic or return value of the code.
It just prepares extended logic for handling RAID10.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Store VD config for other BVDs in the other_bvds array.
This allows handling secondary RAID levels in container_content_ddf.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
The VD config structures of different BVDs in the same SVD may be
different. This pointer stores the other BVDs.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Cleanly increase the seq number when the DDF structures are
written, instead of always setting it back to 1.
Also, make sure that the sequential number of all headers and
VD conf records is the same.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Some RAID BIOSes apparently use hard-coded LBA offsets (presumably
from the end of the disk) for the primary and secondary DDF
structure, ignoring the values given in the DDF anchor. This is
broken BIOS behavior, but it will cause any changes made by MD
(e.g. setting the init_state flag after a full initialization)
to be "forgotten" after the next reboot.
This patch fixes this by using the exiting LBA locations if
available. Verified that this fixes MD+LSI Mega Software RAID
BIOS.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
So far, mdadm only saved the header of the secondary structure.
With this patch, the full secondary DDF structure is saved
consistently, too. Some vendor DDF implementations need it.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
We widely use a "devnum" which is 0 or +ve for md%d devices
and -ve for md_d%d devices.
But I want to be able to use md_%s device names.
So get rid of devnum (a number) and use devnm (a 32char string).
eg.
md0
md_d2
md_home
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm --create /dev/md0 .... /dev/sda1:1024 /dev/sdb1:2048 ...
The size is in K unless a suffix: K M G is given.
The suffix 's' means sectors.
Signed-off-by: NeilBrown <neilb@suse.de>
This is currently only useful for 1.x metadata and will allow an
explicit --data-offset request on command line.
Signed-off-by: NeilBrown <neilb@suse.de>
When adding a spare to a DDF there is some confusion about the
'level' of the container. It is reported by kernel as unknown
-1000000.
I don't know why this broke but until I figure out why and fix it,
this hack gets us going again.
Signed-off-by: NeilBrown <neilb@suse.de>
If a DDF has two arrays sharing devices and one device fails, then
as soon as the spare is used to recover one of the arrays it isn't
spare any more and so is not chosen for the other array.
Work around this for now by allowing a non-spare to be used if it has
enough space.
Reported-by: Albert Pauw <albert.pauw@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If we change some functions to accept 'verbose', where <0 means to be
quiet, in place of 'quiet', then we will be able to merge
'quiet' and 'verbose' together for simplicity.
Signed-off-by: NeilBrown <neilb@suse.de>
malloc should never fail, and if it does it is unlikely
that anything else useful can be done. Best approach is to
abort and let some super-daemon restart.
So define xmalloc, xcalloc, xrealloc, xstrdup which don't
fail but just print a message and exit. Then use those
removing all the tests for failure.
Also replace all "malloc;memset" sequences with 'xcalloc'.
Signed-off-by: NeilBrown <neilb@suse.de>
We need to check every disk to see if it has a particular amount of
space spare, not just every subsequent disk.
Signed-off-by: NeilBrown <neilb@suse.de>
When container is assembled while reshape is active on one of its member
whole container can be required to be blocked from monitoring.
For such purpose field recovery blocked is added to mdinfo structure.
When metadata handler finds active reshape in container it should set
recovery_blocked field to disable whole container monitoring during
reshape.
For arrays that doesn't use containers, recovery_blocked field
has the same value as reshape_active field e.g. super0/1.
In fact,recovery is blocked during reshape for such arrays.
For ddf, metadata handler doesn't set reshape_active field,
so recovery_blocked is not set also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Now that getinfo_super clears the info structure, we need
to make sure the correct values are filled in to info->dev.
Signed-off-by: NeilBrown <neilb@suse.de>
container_content_imsm was setting info->next before calling
getinfo_super_imsm_container which now zeros everything.
So move that assignment to afterwards.
So both imsm and ddf were assuming info->disk.raid_disk means
something but it doesn't. So fix those.
Signed-off-by: NeilBrown <neilb@suse.de>
Some code currently clears 'info' before calling getinfo_super,
some code doesn't.
To be consistent, change it so no caller ever clears 'info',
but ever getinfo_super function must clear it.
Note that ->raid_disk may be meaningful if that 'map' is passed
non-NULL. In that case it is copied out before the structure
is zeroed.
Signed-off-by: NeilBrown <neilb@suse.de>
If a device hasn't been found yet we can still tell if it is
expected to be working, and we must to do to make sure
'working_disks' is correct.
Signed-off-by: NeilBrown <neilb@suse.de>
This is needed to remove devices from mdmon's knowledge when the
device is removed from the md container.
Now that ddf have a remove_from_super we don't need the code
that allows some personalities not to implement this.
Signed-off-by: NeilBrown <neilb@suse.de>
If a RAID1 is meant to have more than 2 device and while it doesn't
have that many, it still has more than 1, then according to the
DDF spec it is "partially optional" rather than "degraded"
So make that so.
Signed-off-by: NeilBrown <neilb@suse.de>
The DDF spec requires we have a phys disk record for every physically
attached device. But it isn't clear what that means in the case
of soft raid in a general purpose Linux computer.
So remove phys disk records for any failed device that is not
active in any array.
Signed-off-by: NeilBrown <neilb@suse.de>
This is a big fragile, but DDF has wierd rules that we aren't really
set up to handle properly.
When we add a device to a degraded array it must be a spare, so
mark it as Rebuilding.
Signed-off-by: NeilBrown <neilb@suse.de>
This is needed to remove devices from mdmon's knowledge when the
device is removed from the md container.
Now that ddf have a remove_from_super we don't need the code
that allows some personalities not to implement this.
Signed-off-by: NeilBrown <neilb@suse.de>
We weren't setting ->vcnum at all when an array was added. This
meant that a subsequent device failure could be assigned to the
wrong array.
Reported-by: Albert Pauw <albert.pauw@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When set_disk is called, we need to check if the disk has changed or
recently appeared, and update everything properly if it has.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ ignore devices with "state_fd < 0" as these have been removed.
2/ Set update 'length' properly and clear 'space'.
Signed-off-by: NeilBrown <neilb@suse.de>
We were setting ->container_member twice in ddf get_info.
Once to currentconf->vcnum,
once to atoi(st->subarray).
Both should be the same.
For consistency with super-intel, use the first.
Signed-off-by: NeilBrown <neilb@suse.de>
the new code for defaulting chunksizes didn't work quite right
- default was set to late in super1/super0/ddf
- defaults would over-ride values of '0' imposed by some levels
- default value wasn't applied to size properly.
Signed-off-by: NeilBrown <neilb@suse.de>
If a device is failed, then don't include it in the reported
container_content, else it might get included in the array.
Reported-by: Albert Pauw <albert.pauw@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When chunk size is not set from command line we need to guess it
depending on metadata given on command line or found on listed devices.
Validate_geometry sets the default for it's metadata if chunk is not set.
For external metadata chunk is set only when creating in a container.
For imsm validate_geometry_imsm_orom is responsible for finding default
chunk depending on container metadata loaded. Container will already know
which controller it is attached to, and have this controllers orom
available.
do_default_chunk indicates that we need to find default chunk and
if validate_geometry fails for some metadata it tells us to reset chunk
that may have been set.
Current solution would set default chunk correctly for imsm only if
container device was given on command line. With the list of devices
chunk was always set to 512.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We previously closed all 'fds' associated with an array in
write_init_super .. sometimes, and sometimes at bad times.
This isn't neat and free_super is a better place to close them.
So make sure free_super always closes the fds that the metadata
manager kept hold of, and stop closing them in write_init_super.
Also add a few more calls to free_super to make sure they really do
get closed.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Now that we check the error return of 'update_super' better, we
much make sure that ddf doesn't incorrectly report that the
superblocks are wrong during assemble.
Signed-off-by: NeilBrown <neilb@suse.de>
Support metadata specific level, layout and chunksize defaults. Kill an
uneeded superswitch methods ahead of adding more for the reshape case.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We more clearly separate out -I on a container, and use
load_container in that case and load_super only for true members.
This removes another use of loaded_container.
Signed-off-by: NeilBrown <neilb@suse.de>
This handles the 'container' part of 'load_super', so we can
soon make them completely separate - it is just confusing to
overload these two.
Signed-off-by: NeilBrown <neilb@suse.de>
It makes more sense to test for container_dev than for subarray
for several places in Create where it then uses container_dev.
This allows us to subsequently remove subarray.
Signed-off-by: NeilBrown <neilb@suse.de>
This allows the info for a single array to be extracted,
so we don't have to write it into st->subarray.
For consistency, implement container_content for super0 and super1,
to just return the mdinfo for the single array.
Signed-off-by: NeilBrown <neilb@suse.de>
We were setting ->container_member twice in ddf get_info.
Once to currentconf->vcnum,
once to atoi(st->subarray).
Both should be the same.
For consistency with super-intel, use the first.
Signed-off-by: NeilBrown <neilb@suse.de>
To accurately detect when an array has been split and is now being
recombined, we need to track which other devices each thinks is
working.
We should never include a device in an array if it thinks that the
primary device has failed.
This patch just allows get_info_super to return a list of devices
and whether they are thought to be working or not.
Signed-off-by: NeilBrown <neilb@suse.de>
If an --update is requested by the relevant metadata doesn't
understand it, print a useful message rather than silently ignoring
the issue.
Signed-off-by: NeilBrown <neilb@suse.de>
The container_enough code change broke ddf as ddf never claimed
'enough' devices. So change it to always claim 'enough' to
restore previous behaviour.
Signed-off-by: NeilBrown <neilb@suse.de>
...i.e. GET_DEVS == (GET_DEVS|SKIP_GONE_DEVS)
A null pointer dereference in Incremental.c can be triggered by
replugging a disk while the old name is in use. When mdadm -I is called
on the new disk we fail the call to sysfs_read(). I audited all the
locations that use GET_DEVS and it appears they can tolerate missing a
drive. So just make SKIP_GONE_DEVS the default behaviour.
Also fix up remaining unchecked usages of the sysfs_read() return value.
Reported-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Support for deleting a subarray out of a container. When all subarrays
are deleted the component devices are converted back into spares, a
--zero-superblock is still needed to kill the remaining metadata at this
point. This operation is blocked when the subarray is active and may
also be blocked by the metadata handler when deleting the subarray might
change the uuid of other active subarrays. For example, with imsm,
deleting subarray 'n' may change the uuid of subarrays with indexes > n.
Deleting a subarray needs to be a container wide event to ensure
disks that record the modified subarray list perceive other disks that
did not receive this change as out of date.
Notes:
The st->subarray parsing in super-intel.c and super-ddf.c is updated to
be more strict now that we are reading user supplied subarray values.
Offline container modification shares actions that mdmon typically
handles so promote is_container_member() and version_to_superswitch()
(formerly find_metadata_methods()) to generic utility functions for the
cases where mdadm performs the operation.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This is needed for imsm where:
1/ we want to report raid_disks as zero to allow mdadm -As to
incorporate all spares
2/ we can't determine stale disks by looking at the event counts.
3/ we can't see per-subarray expectations with the info returned from
the container level ->getinfo_super()
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
These metadata are not expected on partitions, and they have
no way of differentiation whether which is correct if they
are found both on the device and on the last partition.
So if the device is a partition, refuse to read the metadata.
Signed-off-by: NeilBrown <neilb@suse.de>
Matching the functionality already in super0 and super1, when
we first create a container, remove any other recognisable metadata to
ensure it doesn't cause confusion.
Signed-off-by: NeilBrown <neilb@suse.de>
1.x metadata allows a device to be a member of the array while it
is still recoverying. So it is a working member, but is not
completely in-sync.
mdadm/assemble does not understand this distinction and assumes that a
work member is fully in-sync for the purpose of determining if there
are enough in-sync devices for the array to be functional.
So collect the 'recovery_start' value from the metadata and use it in
assemble when determining how useful a given device is.
Reported-by: Mikael Abrahamsson <swmike@swm.pp.se>
Signed-off-by: NeilBrown <neilb@suse.de>
Replace occurrences of ~0ULL to make it clear we are talking about maximal
resync/recovery position.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
We don't need to sprinkle reads of this attribute all over the place,
just once at the entry of read_and_act(). Also, the mdinfo structure
for the array already has a 'resync_start' member, so just reuse that.
Finally, rename get_resync_start() to read_resync_start to make it
consistent with the other sysfs accessors in monitor.c.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
->validate_geometry is called to validate overall parameters,
and to validate each individual device.
If it ever fails, it needs to report the reason, as common code
cannot possible know.
Signed-off-by: NeilBrown <neilb@suse.de>
Previously such things did not exist: ACTIVE and SYNC were either both
set or both clear. Recent changes with reshape means that a device
can be ACTIVE but not yet fully in-sync, so they need to be handled
and included in the array as active devices.
Signed-off-by: NeilBrown <neilb@suse.de>
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>
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>
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 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>
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>
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>
Simple patch to silence some compile warnings that only show up on
64bit arches.
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The 'work_disks' number should be the number that is expected, not the
number found so far. This is needed for Incremental assembly to
start the array at the right time.
Signed-off-by: NeilBrown <neilb@suse.de>
The variable 'i' was being used as a loop variable, and also
for something else inside the loop. So make the larger loop have a
more meaningful name.
Signed-off-by: NeilBrown <neilb@suse.de>
In some cases we should only print an error message if
'devname' is defined. In fact we were only returning
the error at all in that case!!
Signed-off-by: NeilBrown <neilb@suse.de>
mwilck@arcor.de
NeilBrown
Jes Sorensen
Adam Kwolek
Czarnowska, Anna
Dan Williams
Doug Ledford