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>
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 PCI-3.0 Firmware specification allows for option-roms to have
512-byte alignment rather than 2048-byte. As there does not appear to
be a reliable method to detect a PCI-3.0 compliant BIOS from userspace
we allow the imsm platform detection code to presume that a system
modern enough to have an Intel AHCI controller does not have
dangerous/legacy ISA regions in the option-ROM memory space.
An environment variable to disable this behaviour, IMSM_SAFE_OROM_SCAN,
is added in case this presumption is ever proven wrong.
Reported-by: Hans de Goede <hdegoede@redhat.com>
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 falsely returns container info for member arrays. Retrieving
the subarray and container_dev details prior to ->load_super() changes the
result from:
md127 imsm 082c6371:74b5ce03:64972e41:6b0860d5 /dev/md/imsm
md126 imsm 082c6371:74b5ce03:64972e41:6b0860d5 /dev/md/vol0
...to:
md126 /md127/0 3e03aee2:78c3c593:1e8ecaf0:eefb53ed /dev/md/vol0
md127 imsm 082c6371:74b5ce03:64972e41:6b0860d5 /dev/md/imsm
Reported-by: Ignacy Kasperowicz <ignacy.kasperowicz@intel.com>
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>
1/ allow --size to be given with 'G' or 'T' suffix.
2/ allow size to exceed 32bits, and in that case write through sysfs.
Signed-off-by: NeilBrown <neilb@suse.de>
This allows the layout to be parsed after the current level of the
array is know, so that the level doesn't need to be given (otherwise
pointlessly) on the command line.
Signed-off-by: NeilBrown <neilb@suse.de>
Bother Manage_reconfig and Grow_reshape provide for changing
the 'layout' of a faulty array. This is no necessary.
So discard Manage_reconfig and just use Grow_reshape
Signed-off-by: NeilBrown <neilb@suse.de>
With 2.6.30 it is possible to tell the md driver to clip an array to a
size smaller than the real size of the array. This option gives
access to that feature. The size change does not persist
across restarts.
Signed-off-by: NeilBrown <neilb@suse.de>
Using pclose is probably the right thing to do seeing that we
used popen, but as there is no clear need to wait for sendmail
to finish, it isn't really important.
Signed-off-by: NeilBrown <neilb@suse.de>
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>
Since 2.6.16, mdstat responds to select/poll.
So in that case, increase the default poll interval to about 15
minutes.
This ensures that the background load is insignificant.
Signed-off-by: NeilBrown <neilb@suse.de>
externally managed arrays do not (currently) cause utime in
GET_ARRAY_INFO to be updated. So if it is zero, just assume the
current time.
This will cause GET_DISK_INFO to be called more often, but as we do
the scan only every 60 seconds normally, a few extra syscalls isn't
going to make a big difference.
Signed-off-by: NeilBrown <neilb@suse.de>
Dan Williams
NeilBrown
Hans de Goede