If a foreign (i.e. not known to be local) array is discovered
by --incremental assembly, we now assemble it. However we ignore
any name information in the array so as not to potentially create
a name that conflict with a 'local' array.
Also, foreign arrays are always assembled 'read-auto' to avoid writing
anything until the array is actually used.
Signed-off-by: NeilBrown <neilb@suse.de>
If incremental assembly finds an array mentioned in mdadm.conf,
with a 'standard partitioned' name like /dev/md_d0 or /dev/md/d0,
it will not create a partitioned array like it should.
This is because it mishandled the 'devnum' returned by
is_standard.
That is a devnum that does not have the partition-or-not encoded
into it. So we need to check the actual return value of
is_standard and encode the partition-or-not info into the devnum.
Also fix a couple of comments.
Signed-off-by: NeilBrown <neilb@suse.de>
RAID10 is the only raid level that uses the avail char array pointer
during the enough() operation, so it was the only one that saw this.
The code in incremental assumes unconditionally that count_active will
allocate the avail char array, that it might be used by enough, and that
it will need to be freed afterward. Once you make count_active actually
do that, then the oops goes away.
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Certain operations (Detail.c mainly) would print out the metadata of
an array in a format that the scan operation in super0.c and super1.c
would later reject as unknown when it was found in the mdadm.conf file.
Use a consistent format, but also modify the super0 and super1 match
methods to accept the other format without complaint.
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Given an mdadm.conf like the following allow /dev/imsm and /dev/md/r1 to be
created by "mdadm -As".
DEVICES partitions
ARRAY /dev/imsm metadata=imsm auto=md UUID=b98f5dbe-aa859e7b-0e369b89-a80986d4
ARRAY /dev/md/r1 container=/dev/imsm member=0 auto=mdp UUID=3538e39c-b397c2e9-1aa031f9-2bc0eca4
spares=1
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
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>
Previously it was possible to set the WRITEMOSTLY flag when
adding a device to an array, but not to clear the flag when re-adding.
This is now possible with --readwrite.
Signed-off-by: NeilBrown <neilb@suse.de>
.UR URL
text
.UE
is meant to create a hyperlink from the 'text' to the 'URL'.
But I wanted just to have the URL, so UR isn't really the right
tool - the URL gets displayed twice.
So just display the URL in bold and assume man2html etc can recognise
it and do the right thing.
Signed-off-by: NeilBrown <neilb@suse.de>
mdmon cannot remove the pidfile at shutdown becuase it needs to stay
running across the "mount -o remount,ro /" event. When it relaunches
after a reboot there is a good chance that the pid will match what was
there previously. The result is that the "take over for unresponsive
mdmon" logic results in self termination.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
For raid rootfs we cannot run the array unmonitored for any length of
time. At least XFS will not mount/replay the journal if the underlying
block device is readonly (FIXME it also seems that XFS does not always
honor the ro status of the backing device as I was able to hit the
BUG_ON(mddev->ro == 1) in md_write_start... but I digress).
So we need to start mdmon in the initramfs before '/' is mounted and
then restart it after the real rootfs is available. Upon seeing the
--switch-root option, mdmon will kill any victims in the current
/var/run/mdadm directory and then chroot(2) before continuing.
The option is deliberately called 'switch-root' instead of 'chroot' to
hopefully indicate that this is different than doing "chroot mdmon
/dev/imsm".
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Now that mdmon handles sigterm if another monitor wants to take over it
should wait until all managed arrays are clean. So make WaitClean()
available to mdmon and teach try_kill_monitor() to wait on each subarray
in the container.
...since we may be communicating with a dieing process, we need to
block SIGPIPE earlier.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
We generally don't want mdmon to be terminated, but if a SIGTERM gets
through try to leave the monitored arrays in a clean state, block
attempts to mark the array dirty, and stop servicing the socket.
When we are killed by sigterm don't remove the pidfile let that be
cleaned up by the next monitor.
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>
The sha1 routines store the uuids in little endian byte-order, so always
print from msb to lsb. This allows imsm containers to be assembled with
-As.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If initial socket creation fails, EROFS, set a periodic alarm to wake up
the manager and retry. Include a kernel patch that will wake us up if
the mount flags are changed.
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>
Made the mistake of recompiling the F9 mdadm rpm which has a patch to
remove -Werror and add "-Wp,-D_FORTIFY_SOURCE -O2" which turns on lots
of errors:
config.c:568: warning: ignoring return value of asprintf
Assemble.c:411: warning: ignoring return value of asprintf
Assemble.c:413: warning: ignoring return value of asprintf
super0.c:549: warning: ignoring return value of posix_memalign
super0.c:742: warning: ignoring return value of posix_memalign
super0.c:812: warning: ignoring return value of posix_memalign
super1.c:692: warning: ignoring return value of posix_memalign
super1.c:1039: warning: ignoring return value of posix_memalign
super1.c:1155: warning: ignoring return value of posix_memalign
super-ddf.c:508: warning: ignoring return value of posix_memalign
super-ddf.c:645: warning: ignoring return value of posix_memalign
super-ddf.c:696: warning: ignoring return value of posix_memalign
super-ddf.c:715: warning: ignoring return value of posix_memalign
super-ddf.c:1476: warning: ignoring return value of posix_memalign
super-ddf.c:1603: warning: ignoring return value of posix_memalign
super-ddf.c:1614: warning: ignoring return value of posix_memalign
super-ddf.c:1842: warning: ignoring return value of posix_memalign
super-ddf.c:2013: warning: ignoring return value of posix_memalign
super-ddf.c:2140: warning: ignoring return value of write
super-ddf.c:2143: warning: ignoring return value of write
super-ddf.c:2147: warning: ignoring return value of write
super-ddf.c:2150: warning: ignoring return value of write
super-ddf.c:2162: warning: ignoring return value of write
super-ddf.c:2169: warning: ignoring return value of write
super-ddf.c:2172: warning: ignoring return value of write
super-ddf.c:2176: warning: ignoring return value of write
super-ddf.c:2181: warning: ignoring return value of write
super-ddf.c:2686: warning: ignoring return value of posix_memalign
super-ddf.c:2690: warning: ignoring return value of write
super-ddf.c:3070: warning: ignoring return value of posix_memalign
super-ddf.c:3254: warning: ignoring return value of posix_memalign
bitmap.c:128: warning: ignoring return value of posix_memalign
mdmon.c:94: warning: ignoring return value of write
mdmon.c:221: warning: ignoring return value of pipe
mdmon.c:327: warning: ignoring return value of write
mdmon.c:330: warning: ignoring return value of chdir
mdmon.c:335: warning: ignoring return value of dup
monitor.c:415: warning: rv may be used uninitialized in this function
...some of these like the write() ones are not so trivial so save those
fixes for the next patch.
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>
Root file systems backed by external metadata arrays need to be
explicitly checkpointed near the time the rootfs is marked readonly as
userspace will not have an opportunity to react to the final shutdown of
the array.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Set the safemode timeout to a small value to get the array marked clean as
soon as possible. We don't write 'clean' directly as it may cause mdmon to
miss a 'write-pending' event.
Include a couple fixes to sysfs_set_safemode():
1/ 0 pad the milliseconds field
2/ workaround input truncation in the kernel
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>
When arrays do not startup correctly it would be nice to know why. Need
to move the dprintf definition to mdadm.h
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>
zero-initialize the serial buffer to handle cases where the response is
less than MAX_RAID_SERIAL_LEN.
Tested-by: Jacek Danecki <jacek.danecki@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If we add a device to a linear array which is a difference size
to the other devices in the array then, for v1.x metadata, we need to
make sure the size is correctly reflected in the superblock.
Showing e.g.
near=1, far=2
for the 'far2' layout of raid10 is confusing even though there is a
sense in which is it correct.
Make it less confusing by only printing whichever number is not 1.
If both are 1, make that clear too (i.e. no redundancy).
When adding a device to an array, we check that it is large enough.
Currently the check makes sure there is also room for a reasonably
sized bitmap. But if the array doesn't have a bitmap, then this test
might be too restrictive.
So when adding, only insist there is enough space for the current
bitmap.
When Creating, still require room for the standard sized bitmap.
This resolved Debian Bug 500309
When -I get a new device for a container and tries to incrementally
assemble the container array, it calls sysfs_set_array to create the
array without first checking if it already exists. This produces
unpleasant error messages.
So check first.
Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown
Doug Ledford
Dan Williams