Since commit 30bee0201, the anchor is updated from the active
DDF header. This requires fixing the header type before the
anchor is written.
The LSI Software RAID code will reject DDF meta data with wrong
anchor type and will erase all meta data when it encounters
such a broken anchor. Thus starting Linux md once on a system
with LSI RAID BIOS may cause the meta data to get destroyed.
Signed-off-by: NeilBrown <neilb@suse.de>
It is best to keep strings all together so that they
are easier to search for in the source code.
If a string is so long that it looks ugly one line,
them maybe it should be broken into multiple lines
for display too.
Only strings which contain a newline can be broken
into multiple lines:
"It is OK to\n"
"break this string\n"
Signed-off-by: NeilBrown <neilb@suse.de>
make dprintf() print program name and __func__, so that
this messaging is consistent.
Also remove all __func__ messages from pr_err(). We shouldn't
leak that internal data in error message.
If we really want function name there, we new pr_XXX might
be wanted.
Signed-off-by: NeilBrown <neilb@suse.de>
mdadm fails to build on ppc64 and ppc64le architectures.
===
super-ddf.c: In function '_set_config_size':
super-ddf.c:2849:4: error: format '%llx' expects argument of type 'long long unsigned int', but argument 6 has type '__u64' [-Werror=format=]
pr_err("%s: %x:%x: workspace size 0x%llx too big, ignoring\n",
^
super-ddf.c:2855:2: error: format '%llx' expects argument of type 'long long unsigned int', but argument 6 has type '__u64' [-Werror=format=]
dprintf("%s: %x:%x config_size %llx, DDF structure is %llx blocks\n",
^
cc1: all warnings being treated as errors
<builtin>: recipe for target 'super-ddf.o' failed
===
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1125883
Signed-off-by: <menantea@linux.vnet.ibm.com>
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
Signed-off-by: NeilBrown <neilb@suse.de>
process_update already checks update->len, for all but
the 'magic', prepare_update doesn't at all.
So add tests to prepare_update that we don't exceed the buffer.
This will consequently protect process_update from looking
for a 'magic' which isn't there.
Reported-by: Vincent Berg <vberg@ioactive.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If 'prepare_update' fails for some reason there is little
point continuing on to 'process_update'.
For now only malloc failures are caught, but other failures
will be considered in future.
Signed-off-by: NeilBrown <neilb@suse.de>
I'm not sure what this was supposed to do, but it isn't needed
as creating on a container and on individual devices (in a container)
work fine already.
Signed-off-by: NeilBrown <neilb@suse.de>
As this code runs in 'monitor' it cannot just free memory,
it must add it to a list for 'manager' to free.
Fortunate update->space_list exists for just this purpose.
dl->devname might be small, so put it in update->space and
put dl in update->space_list.
Signed-off-by: NeilBrown <neilb@suse.de>
Infrastructure is there, so use it.
This requires making sure that ->data_offset is correctly set, even
for containers.
Signed-off-by: NeilBrown <neilb@suse.de>
Each place the uses "get_extents" has slightly different search code
to look through the result.
Factor this out into a single find_space() function.
This is will make it easier to add --data-offset support.
Signed-off-by: NeilBrown <neilb@suse.de>
The DDF "RAID1E" level is similar to md "raid10".
So use raid10 to support RAID1E, and create RAID1E for raid10
configs not already supported.
Signed-off-by: NeilBrown <neilb@suse.de>
We currently copy the anchor to both primary and secondary
blocks.
This assumes that the anchor is uptodate, but it might not be.
We should trust the 'active' block and copy from there.
Signed-off-by: NeilBrown <neilb@suse.de>
- we weren't updating this timestamp at all
- the 'vd_config' seqnum was updated on every write of the metadata,
which is excessive. Just update it when there is a change.
Signed-off-by: NeilBrown <neilb@suse.de>
As we are range-checking 'cd', there is a chance that it is not
in-range. In that case we should include all array indexes with 'cd'
inside the range-tested branch.
Signed-off-by: NeilBrown <neilb@suse.de>
The phys disks table should list all disks, but if the metadata
is corrupt, it might not even list the disk it was read from.
So check for and report any known disks that aren't listed.
Signed-off-by: NeilBrown <neilb@suse.de>
The "used_pdes" value counts the number of physdisk entries that
are in used.
It may not be the last one in use as there may be unused slots in
the middle.
So when were are iterating over phys disks, we need to use max_pdes
and skip unused entries.
Signed-off-by: NeilBrown <neilb@suse.de>
It is possible that one device has seem some reconfig but the other
hasn't. In that case they are still the "same" DDF, even though
one might be older. Such age will be detected by 'seq' differences.
If A is new and B is old, then it is import that
mdadm -I B
mdadm -I A
doesn't get confused because A has the same uuid as B, but compare_super fails.
So: if the seq numbers are different, then just accept as two
different superblocks.
If they are the same, then look to copy data from new to old.
Signed-off-by: NeilBrown <neilb@suse.de>
Testing 'c' and then using 'vdc' assumes that the two are in sync,
but sometimes they aren't.
Testing 'vdc' is safer.
This avoids a crash in some cases when failing/removing/added devices
to a DDF.
Signed-off-by: NeilBrown <neilb@suse.de>
It is conceivable that ->pdnum could be -1, though only if
the metadata is corrupt.
We should be careful not to use it if it is.
Also remove an assignment for pdnum to ->container_member.
This is never used and cannot possibly mean anything.
Signed-off-by: NeilBrown <neilb@suse.de>
Also don't treat two devices with different seq numbers as completely
unrelated.
This allows split-brain detection to work properly for ddf.
Signed-off-by: NeilBrown <neilb@suse.de>
When we call "getinfo_super", we report the working/failed status
of the particular device, and also (via the 'map') the working/failed
status of every other device that this metadata is aware of.
It is important that the way we calculate "working or failed" is
consistent.
As it is, getinfo_super_ddf() will report a spare as "working", but
every other device will see it as "failed", which leads to failure to
assemble arrays with spares.
For getinfo_super_ddf (i.e. for the container), a device is assumed
"working" unless flagged as DDF_Failed.
For getinfo_super_ddf_bvd (for a member array), a device is assumed
"failed" unless DDF_Online is set, and DDF_Failed is not set.
Reported-by: "David F." <df7729@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
See commit 357ac10678
which made a similar change for super-intel, and really should have
fixed DDF at the same time.
Signed-off-by: NeilBrown <neilb@suse.de>
Some vendor DDF structures interpret workspace_lba
very differently then us. Make a sanity check on the value
before using it for config_size.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
The sequence number check in compare_super_ddf was broken,
anchor sequence number is always -1.
With this patch, mdadm will refuse to add a disk with non-matching
sequence number.
This fixes Francis Moreau's problem reported with subject
"mdadm 3.3 fails to kick out non fresh disk".
FIXME: More work is needed here. Currently mdadm won't even add the
disk to the container, that's wrong. It should be added as a spare.
Signed-off-by: NeilBrown <neilb@suse.de>
Print an array name in brief output, like IMSM does.
SUSE's YaST2 (libstorage) needs this in order to detect MD arrays
during installation.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
The same algorithm was used in getinfo_super_ddf_bvd and
container_content_ddf. Put it in a common function.
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
If there isn't, we currently write the second copy at some
random location :-)
Reported-and-tested-by: Francis Moreau <francis.moro@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some fake RAID BIOSes (in particular, LSI ones) change the
VD GUID at every boot. These GUIDs are not suitable for
identifying an array. Luckily the header GUID appears to
remain constant.
We construct a pseudo-UUID from the header GUID and those
properties of the subarray that we expect to remain constant.
This is only array name and index; all else might change e.g.
during grow.
Don't do this for all non-MD arrays, only for those known
to use varying volume GUIDs.
This patch obsoletes my previous patch "DDF: new algorithm
for subarray UUID"
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Martin Wilck
NeilBrown
Guy Menanteau
Cristian Rodríguez
mwilck@arcor.de