Xiao Ni [Tue, 9 Feb 2021 09:39:51 +0000 (17:39 +0800)]
It should be FAILED when raid has not enough active disks
It can't remove the disk if there are not enough disks. For example, raid5 can't remove the
second disk. If the second disk is unplug from machine, it's better show missing and the raid
should be FAILED. It's better for administrator to monitor the raid.
Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
mdmonitor: check if udev has finished events processing
If mdmonitor is awaken by event, wait for udev to finish
events processing, to eliminate the race between udev and mdadm
when spare has been added and need to be moved by mdmonitor
Mariusz Tkaczyk [Wed, 13 Jan 2021 08:58:45 +0000 (09:58 +0100)]
imsm: use saved fds during migration
IMSM super keeps open descriptors in super->disks structure, they are
reliable and should be chosen if possible. The repeatedly called open
and close during reshape generates redundant udev change events on
each member drive.
Zhao Heming [Wed, 3 Feb 2021 00:22:51 +0000 (08:22 +0800)]
super1.c: avoid useless sync when bitmap switches from clustered to none
With kernel commit 480523feae58 ("md: only call set_in_sync() when it
is expected to succeed."), mddev->in_sync in clustered array is always
zero. It makes metadata resync_offset to always zero.
When assembling a clusterd array with "-U no-bitmap" option, kernel
md layer "mddev->resync_offset == 0" and "mddev->bitmap == NULL" will
trigger raid1 do sync on every bitmap chunk. the sync action is useless,
we should avoid it.
Related kernel flow:
```
md_do_sync
mddev->pers->sync_request
raid1_sync_request
md_bitmap_start_sync(mddev->bitmap, sector_nr, &sync_blocks, 1)
__bitmap_start_sync(bitmap, offset,&blocks1, degraded)
if (bitmap == NULL) {/* FIXME or bitmap set as 'failed' */
*blocks = 1024;
return 1; /* always resync if no bitmap */
}
```
NeilBrown [Fri, 26 Feb 2021 01:02:36 +0000 (12:02 +1100)]
Grow: be careful of corrupt dev_roles list
I've seen a case where the dev_roles list of a linear array
was corrupt. ->max_dev was > 128 and > raid_disks, and the
extra slots were '0', not 0xFFFE or 0xFFFF.
This caused problems when a 128th device was added.
So:
1/ make Grow_Add_device more robust so that if numbers
look wrong, it fails-safe.
2/ make examine_super1() report details if the dev_roles
array is corrupt.
Nigel Croxon [Wed, 20 Jan 2021 20:05:42 +0000 (15:05 -0500)]
mdadm: fix reshape from RAID5 to RAID6 with backup file
Reshaping a 3-disk RAID5 to 4-disk RAID6 will cause a hang of
the resync after the grow.
Adding a spare disk to avoid degrading the array when growing
is successful, but not successful when supplying a backup file
on the command line. If the reshape job is not already running,
set the sync_max value to max.
Lidong Zhong [Mon, 14 Dec 2020 14:51:33 +0000 (22:51 +0800)]
Dump: get stat from a wrong metadata file when restoring metadata
The dumped metadata files are shown as below
localhost:~ # ll -ih test/
total 16K 34565564 -rw-r--r-- 2 root root 1.0G Dec 14 21:15
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-3 34565563 -rw-r--r-- 2 root root 1.0G Dec 14 21:15
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-4 34565563 -rw-r--r-- 2 root root 1.0G Dec 14 21:15 sda 34565564 -rw-r--r-- 2 root root 1.0G Dec 14 21:15 sdb
It reports such error when trying to restore metadata for /dev/sda
localhost:~ # mdadm --restore=test /dev/sda
mdadm: test/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-4 is not the same
size as /dev/sda - cannot restore.
It's because the stb value has been changed to other metadata file in
the while statement.
Mariusz Tkaczyk [Fri, 11 Dec 2020 11:28:38 +0000 (12:28 +0100)]
Incremental: Remove redundant spare movement logic
If policy is set then mdmonitor is responsible for moving spares.
This logic is reduntant and potentialy dangerus, spare could be moved at
initrd stage depending on drives appearance order.
Tkaczyk Mariusz [Thu, 15 Oct 2020 08:45:29 +0000 (10:45 +0200)]
udev: start grow service automatically
Grow continue via service or fork is started during raid assembly.
If raid was assembled in initrd it will be newer restarted after
switch root.
Add udev support for starting mdadm-grow-continue service.
Kinga Tanska [Thu, 22 Oct 2020 12:22:29 +0000 (14:22 +0200)]
Make target to install binaries only
Make install causes installation of binaries, udev and man.
This commit contains new target make install-bin, which
results in installation of binaries only.
Zhao Heming [Sat, 24 Oct 2020 09:43:12 +0000 (17:43 +0800)]
mdadm/Detail: show correct state for clustered array
After kernel md module commit 480523feae581, in clustered env,
mddev->in_sync always zero, it will make array.state never set
up MD_SB_CLEAN. it causes "mdadm -D /dev/mdX" show state 'active'
all the time.
bitmap.c: add a new API IsBitmapDirty() to support inquiry bitmap
dirty or clean.
Mariusz Tkaczyk [Wed, 4 Nov 2020 09:02:36 +0000 (10:02 +0100)]
mdadm: Unify forks behaviour
If mdadm is run by udev or systemd, it gets a pipe as each stream.
Forks in the background may run after an event or service has been
processed when udev is detached from pipe. As a result process
fails quietly if any message is written.
To prevent from it, each fork has to close all parent streams. Leave
stderr and stdout opened only for debug purposes.
Unify it across all forks. Introduce other descriptors detection by
scanning /proc/self/fd directory. Add generic method for
managing systemd services.
Mariusz Tkaczyk [Tue, 24 Nov 2020 13:15:15 +0000 (14:15 +0100)]
imsm: update num_data_stripes according to dev_size
If array was created in UEFI there is possibility that
member size is not rounded to 1MB. After any size reconfiguration
it will be rounded down to 1MB per each member but the old
component size will remain in metadata.
During reshape old array size is calculated from component size because
dev_size is not a part of map and is bumped to new value quickly.
It may result in size mismatch if array is assembled during reshape.
If difference in calculated size and dev_size is observed try to fix it.
num_data_stripes value can be safety updated to smaller value if array
doesn't occuppy whole reserved component space.
Mariusz Tkaczyk [Tue, 24 Nov 2020 12:39:49 +0000 (13:39 +0100)]
Create.c: close mdfd and generate uevent
During mdfd closing change event is not generated because open() is
called before start watching mddevice by udev.
Device is ready at this stage. Unblock device, close fd and
generate event to give a chance next layers to work.
Lidong Zhong [Sun, 22 Nov 2020 15:12:29 +0000 (23:12 +0800)]
Detail: fix segfault during IMSM raid creation
It can be reproduced with non IMSM hardware and IMSM_NO_PLATFORM
environmental variable set. The array state is inactive when creating
an IMSM container. And the structure info is NULL because load_super()
always fails since no intel HBA information could be obtained.
Signed-off-by: Lidong Zhong <lidong.zhong@suse.com> Reported-by: Tkaczyk Mariusz <mariusz.tkaczyk@intel.com> Fixes: 64bf4dff3430 (Detail: show correct raid level when the array is inactive)
NeilBrown [Wed, 14 Oct 2020 02:12:48 +0000 (13:12 +1100)]
Super1: allow RAID0 layout setting to be removed.
Once the RAID0 layout has been set, the RAID0 array cannot be assembled
on an older kernel which doesn't understand layouts.
This is an intentional safety feature, but sometimes people need the
ability to roll-back to a previously working configuration.
So add "--update=layout-unspecified" to remove RAID0 layout information
from the superblock.
Running "--assemble --update=layout-unspecified" will cause the assembly
the fail when run on a newer kernel, but will allow it to work on
an older kernel.
Stop reporting any events from container but still track them,
it is important for spare migration.
Stop mdmonitor if no redundant array is presented in mdstat.
There is nothing to follow.
After 52209d6ee118 ("Monitor: release /proc/mdstat fd when no arrays
present") mdstat fd is closed if mdstat is empty or cannot be opened.
It causes that monitor is not able to select on mdstat. Select
doesn't fail because it gets valid descriptor to a different resource.
As a result any new event will be unnoticed until timeout (delay).
Refresh mdstat after wake up, don't poll on wrong resource.
Detail: show correct raid level when the array is inactive
Sometimes the raid level in the output of `mdadm -D /dev/mdX` is
misleading when the array is in inactive state. Here is a testcase for
introduction.
1\ creating a raid1 device with two disks. Specify a different hostname
rather than the real one for later verfication.
node1:~ # mdadm --create /dev/md0 --homehost TESTARRAY -o -l 1 -n 2 /dev/sdb
/dev/sdc
2\ remove one of the devices and reboot
3\ show the detail of raid1 device
node1:~ # mdadm -D /dev/md127
/dev/md127:
Version : 1.2
Raid Level : raid0
Total Devices : 1
Persistence : Superblock is persistent
State : inactive
Working Devices : 1
You can see that the "Raid Level" in /dev/md127 is raid0 now.
After step 2\ is done, the degraded raid1 device is recognized
as a "foreign" array in 64-md-raid-assembly.rules. And thus the
timer to activate the raid1 device is not triggered. The array
level returned from GET_ARRAY_INFO ioctl is 0. And the string
shown for "Raid Level" is
str = map_num(pers, array.level);
And the definition of pers is
mapping_t pers[] = {
{ "linear", LEVEL_LINEAR},
{ "raid0", 0},
{ "0", 0}
...
So the misleading "raid0" is shown in this testcase.
Changelog:
v1: don't show "Raid Level" when array is inactive Signed-off-by: Lidong Zhong <lidong.zhong@suse.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Xiao Ni [Mon, 27 Jul 2020 01:14:20 +0000 (09:14 +0800)]
Specify nodes number when updating cluster nodes
Now it allows updating cluster nodes without specify --nodes. It can write superblock
with zero nodes. It can break the current cluster. Add this check to avoid this problem.
v2: It needs check c.update first to avoid NULL pointer reference
v3: Wol points the typo error
Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
allenpeng [Fri, 12 Jun 2020 09:00:39 +0000 (17:00 +0800)]
mdadm/Grow: prevent md's fd from being occupied during delayed time
If we start reshaping on md which shares sub-devices with another
resyncing md, it may be forced to wait for others to complete. mdadm
occupies the md's fd during this time, which causes the md can not be
stopped and the filesystem can not be mounted on the md. We can close
md's fd earlier to solve this problem.
Reproducible Steps:
1. create two partitions on sda, sdb, sdc, sdd
2. create raid1 with sda1, sdb1
mdadm -C /dev/md1 --assume-clean -l1 -n2 /dev/sda1 /dev/sdb1
3. create raid5 with sda2, sdb2, sdc2
mdadm -C /dev/md2 --assume-clean -l5 -n3 /dev/sda2 /dev/sdb2 /dev/sdc2
4. start resync at md1
echo repair > /sys/block/md1/md/sync_action
5. reshape raid5 to raid6
mdadm -a /dev/md2 /dev/sdd2
mdadm --grow /dev/md2 -n4 -l6 --backup-file=/root/md2-backup
Now mdadm is occupying the fd of md2, causing md2 unable to be stopped
6.Try to stop md2, an error message shows
mdadm -S /dev/md2
mdadm: Cannot get exclusive access to /dev/md3:Perhaps a running process,
mounted filesystem or active volume group?
Reviewed-by: Alex Wu <alexwu@synology.com> Reviewed-by: BingJing Chang <bingjingc@synology.com> Reviewed-by: Danny Shih <dannyshih@synology.com> Signed-off-by: ChangSyun Peng <allenpeng@synology.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
David Favro [Sat, 23 May 2020 12:24:59 +0000 (08:24 -0400)]
Detect too-small device: error rather than underflow/crash
For 1.x metadata, when the user requested creation of an array on
component devices that were too small even to hold the superblock,
an undetected integer wraparound (underflow) resulted in an enormous
computed size which resulted in various follow-on errors such as
floating-point exception.
This patch detects this condition, prints a reasonable diagnostic
message, and refuses to continue.
Signed-off-by: David Favro <dfavro@meta-dynamic.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Guoqing Jiang [Mon, 18 May 2020 21:53:36 +0000 (23:53 +0200)]
restripe: fix ignoring return value of ‘read’ and lseek
Got below error when run "make everything".
restripe.c: In function ‘test_stripes’:
restripe.c:870:4: error: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Werror=unused-result]
read(source[i], stripes[i], chunk_size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix it by check the return value of ‘read’, and free memory
in the failure case.
And check the return value of lseek as well per Jes's comment.
Jes Sorensen [Tue, 19 May 2020 00:19:53 +0000 (20:19 -0400)]
Include count for \0 character when using strncpy to implement strdup.
We have to include the \0 character in the length when copying a
string with strncpy() for which length was found with strlen().
Otherwise the destination will not get null terminated - except that
we explicitly zeroed it out earlier.
Guoqing Jiang [Mon, 18 May 2020 21:53:35 +0000 (23:53 +0200)]
uuid.c: split uuid stuffs from util.c
Currently, 'make raid6check' is build broken since commit b06815989
("mdadm: load default sysfs attributes after assemblation").
/usr/bin/ld: sysfs.o: in function `sysfsline':
sysfs.c:(.text+0x2707): undefined reference to `parse_uuid'
/usr/bin/ld: sysfs.c:(.text+0x271a): undefined reference to `uuid_zero'
/usr/bin/ld: sysfs.c:(.text+0x2721): undefined reference to `uuid_zero'
Apparently, the compile of mdadm or raid6check are coupled with uuid
functions inside util.c. However, we can't just add util.o to CHECK_OBJS
which raid6check is needed, because it caused other worse problems.
So, let's introduce a uuid.c file which is indenpended file to fix the
problem, all the contents are splitted from util.c.
Tkaczyk Mariusz [Fri, 15 May 2020 09:23:14 +0000 (11:23 +0200)]
Makefile: add EXTRAVERSION support
Add optional EXTRAVERSION parameter to Makefile and allow to mark version
by user friendly label. It might be useful when creating custom
spins of mdadm, or labeling some instance in between major releases.
Mariusz Tkaczyk [Tue, 5 May 2020 10:17:17 +0000 (12:17 +0200)]
Assemble.c: respect force flag.
If the array is dirty handler will set resync_start to 0 to inform kernel
that resync is needed. RWH affects only raid456 module, for other
levels array will be started even array is degraded and resync cannot be
performed.
Force is really meaningful for raid456. If array is degraded and resync
is requested, kernel will reject an attempt to start the array. To
respect force, it has to be marked as clean (this will be done for each
array without PPL) and remove the resync request (only for raid 456).
Data corruption may occur so proper warning is added.
mdadm: No super block found on /dev/ram1 (Expected magic a92b4efc, got 00000000)
mdadm: no RAID superblock on /dev/ram1
mdadm: /dev/md111 assembled from 1 drive - need all 2 to start it (use --run to insist).
The mdadm say that it assembled but mdadm does not create /dev/md111.
The message is wrong.
After applying this patch, mdadm reports error correctly as following.
mdadm: No super block found on /dev/ram1 (Expected magic a92b4efc, got 00000000)
mdadm: no RAID superblock on /dev/ram1
mdadm: /dev/ram1 has no superblock - assembly aborted
Signed-off-by: Gioh Kim <gi-oh.kim@cloud.ionos.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
New drive in container always appears as spare. Manager is able to
handle that, and queues appropriative update to monitor.
No update from mdadm side has to be processed, just insert the drive and
ping the mdmon. Metadata has to be written if no mdmon is running (case
for Raid0 or container without arrays).
If bare drive is added very early on startup (by custom bare rule),
there is possiblity that mdmon was not restarted after switch root. Old
one is not able to handle new drive. New one fails because there is
drive without metadata in container and metadata cannot be loaded.
To prevent this, write spare metadata before adding device
to container. Mdmon will overwrite it (same case as spare migration,
if drive appears it writes the most recent metadata).
Metadata has to be written only on new drive before sysfs_add_disk(),
don't race with mdmon if running.
Coly Li [Fri, 10 Apr 2020 16:24:46 +0000 (00:24 +0800)]
Monitor: improve check_one_sharer() for checking duplicated process
When running mdadm monitor with scan mode, only one autorebuild process
is allowed. check_one_sharer() checks duplicated process by following
steps,
1) Read autorebuild.pid file,
- if file does not exist, no duplicated process, go to 3).
- if file exists, continue to next step.
2) Read pid number from autorebuild.pid file, then check procfs pid
directory /proc/<PID>,
- if the directory does not exist, no duplicated process, go to 3)
- if the directory exists, print error message for duplicated process
and exit this mdadm.
3) Write current pid into autorebuild.pid file, continue to monitor in
scan mode.
The problem for the above step 2) is, if after system reboots and
another different process happens to have exact same pid number which
autorebuild.pid file records, check_one_sharer() will treat it as a
duplicated mdadm process and returns error with message "Only one
autorebuild process allowed in scan mode, aborting".
This patch tries to fix the above same-pid-but-different-process issue
by one more step to check the process command name,
1) Read autorebuild.pid file
- if file does not exist, no duplicated process, go to 4).
- if file exists, continue to next step.
2) Read pid number from autorebuild.pid file, then check procfs file
comm with the specific pid directory /proc/<PID>/comm
- if the file does not exit, it means the directory /proc/<PID> does
not exist, go to 4)
- if the file exits, continue next step
3) Read process command name from /proc/<PIC>/comm, compare the command
name with "mdadm" process name,
- if not equal, no duplicated process, goto 4)
- if strings are equal, print error message for duplicated process
and exit this mdadm.
4) Write current pid into autorebuild.pid file, continue to monitor in
scan mode.
Now check_one_sharer() returns error for duplicated process only when
the recorded pid from autorebuild.pid exists, and the process has exact
same command name as "mdadm".
When adding a device to a container mdadm has to close its file
descriptor before sysfs_add_disk(). This generates change event.
There is race possibility because metadata is already written and other
-I process can place drive differently. As a result device can be added
to two containers simultaneously.
From IMSM perspective there is no need to react for change event. IMSM
doesn't support stacked devices.
Blazej Kucman [Wed, 19 Feb 2020 09:54:49 +0000 (10:54 +0100)]
imsm: pass subarray id to kill_subarray function
After patch b6180160f ("imsm: save current_vol number")
current_vol for imsm is not set and kill_subarray()
cannot determine which volume has to be deleted.
Volume has to be passed as "subarray_id".
The parameter affects only IMSM metadata.
Xiao Ni [Tue, 11 Feb 2020 13:44:15 +0000 (21:44 +0800)]
Remove the legacy whitespace
The whitespace between Environment= and the true value causes confusion.
To avoid confusing other people in future, remove the whitespace to keep
it a simple, unambiguous syntax
Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Coly Li [Mon, 24 Feb 2020 11:34:09 +0000 (12:34 +0100)]
mdadm.8: add note information for raid0 growing operation
When growing a raid0 device, if the new component disk size is not
big enough, the grow operation may fail due to lack of backup space.
The minimum backup space should be larger than:
LCM(old, new) * chunk-size * 2
where LCM() is the least common multiple of the old and new count of
component disks, and "* 2" comes from the fact that mdadm refuses to
use more than half of a spare device for backup space.
There are users reporting such failure when they grew a raid0 array
with small component disk. Neil Brown points out this is not a bug
and how the failure comes. This patch adds note information into
mdadm(8) man page in the Notes part of GROW MODE section to explain
the minimum size requirement of new component disk size or external
backup size.
Reviewed-by: Petr Vorel <pvorel@suse.cz> Cc: NeilBrown <neilb@suse.de> Cc: Jes Sorensen <jsorensen@fb.com> Cc: Paul Menzel <pmenzel@molgen.mpg.de> Cc: Wols Lists <antlists@youngman.org.uk> Cc: Nix <nix@esperi.org.uk> Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Blazej Kucman [Fri, 17 Jan 2020 14:24:04 +0000 (15:24 +0100)]
imsm: fill working_disks according to metadata.
Imsm tracks as "working_disk" each visible drive.
Assemble routine expects that the value will return count
of active member drives recorded in metadata.
As a side effect "--no-degraded" doesn't work correctly for imsm.
Align this field to others.
Added check, if the option --no-degraded is called with --scan.
Kinga Tanska [Tue, 10 Dec 2019 11:21:21 +0000 (12:21 +0100)]
Change warning message
In commit 039b7225e6 ("md: allow creation of mdNNN arrays via
md_mod/parameters/new_array") support for name like mdNNN
was added. Special warning, when kernel is unable to handle
request, was added in commit 7105228e19
("mdadm/mdopen: create new function create_named_array for
writing to new_array"), but it was not adequate enough,
because in this situation mdadm tries to do it in old way.
This commit changes warning to be more relevant when
creating RAID container with "/dev/mdNNN" name and mdadm
back to old approach.
dann frazier [Mon, 9 Dec 2019 20:54:13 +0000 (13:54 -0700)]
Respect $(CROSS_COMPILE) when $(CC) is the default
Commit 1180ed5 told make to only respect $(CROSS_COMPILE) when $(CC)
was unset. But that will never be the case, as make provides
a default value for $(CC). Change this logic to respect $(CROSS_COMPILE)
when $(CC) is the default. Patch originally by Helmet Grohne.
Fixes: 1180ed5 ("Makefile: make the CC definition conditional") Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
NeilBrown [Mon, 4 Nov 2019 03:27:49 +0000 (14:27 +1100)]
Assemble: add support for RAID0 layouts.
If you have a RAID0 array with varying sized devices
on a kernel before 5.4, you cannot assembling it on
5.4 or later without explicitly setting the layout.
This is now possible with
--update=layout-original (For 3.13 and earlier kernels)
or
--update=layout-alternate (for 3.14 and later kernels)
NeilBrown [Mon, 4 Nov 2019 03:27:49 +0000 (14:27 +1100)]
Create: add support for RAID0 layouts.
Since Linux 5.4 a layout is needed for RAID0 arrays with
varying device sizes.
This patch makes the layout of an array visible (via --examine)
and sets the layout on newly created arrays.
--layout=dangerous
can be used to avoid setting a layout so that they array
can be used on older kernels.
Blazej Kucman [Mon, 2 Dec 2019 09:52:05 +0000 (10:52 +0100)]
imsm: Change the way of printing nvme drives in detail-platform.
Change NVMe controller path to device node path
in mdadm --detail-platform and print serial number.
The method imsm_read_serial always trimes serial to
MAX_RAID_SERIAL_LEN, added parameter 'serial_buf_len'
will be used to check the serial fit
to passed buffor, if not, will be trimed.
Blazej Kucman [Fri, 29 Nov 2019 14:21:08 +0000 (15:21 +0100)]
imsm: return correct uuid for volume in detail
Fixes the side effect of the patch b6180160f ("imsm: save current_vol number")
- wrong UUID is printed in detail for each volume.
New parameter "subarray" is added to determine what info should be extracted
from metadata (subarray or container).
The parameter affects only IMSM metadata.
Xiao Yang [Wed, 27 Nov 2019 03:59:24 +0000 (11:59 +0800)]
Manage: Remove the legacy code for md driver prior to 0.90.03
Previous re-add operation only calls ioctl(HOT_ADD_DISK) for array without
metadata(e.g. mdadm -B/--build) when md driver is less than 0.90.02, but
commit 091e8e6 breaks the logic and current re-add operation can call
ioctl(HOT_ADD_DISK) even if md driver is 0.90.03.
This issue is reproduced by 05r1-re-add-nosuper:
------------------------------------------------
++ die 'resync or recovery is happening!'
++ echo -e '\n\tERROR: resync or recovery is happening! \n'
ERROR: resync or recovery is happening!
------------------------------------------------
Fixes: 091e8e6("Manage: Remove all references to md_get_version()") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Xiao Yang <ice_yangxiao@163.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
NeilBrown [Thu, 31 Oct 2019 04:15:38 +0000 (15:15 +1100)]
super-intel: don't mark structs 'packed' unnecessarily
super-intel marks a number of structures 'packed', but this
doesn't change the layout - they are already well organized.
This is a problem a gcc warns when code takes the address
of a field in a packet struct - as super-intel sometimes does.
So remove the marking where isn't needed.
Do ensure this does introduce a regression, add a compile-time
assertion that the size of the structure is exactly the value
it had before the 'packed' notation was removed.
Note that a couple of structure do need to be packed.
As the address of fields is never taken, that is safe.
NeilBrown [Tue, 29 Oct 2019 23:32:41 +0000 (10:32 +1100)]
mdcheck: use ${} to pass variable to mdcheck
$MDADM_CHECK_DURATION allows the value to be split on spaces.
${MDADM_CHECK_DURATION} avoids such splitting.
Making this change removes the need for double quoting when setting
the default Environment, and means that double quoting isn't needed
in the EnvironmentFile.
NeilBrown [Tue, 29 Oct 2019 23:32:41 +0000 (10:32 +1100)]
mdcheck: when mdcheck_start is enabled, enable mdcheck_continue too.
mdcheck_continue continues a regular array scan that was started by
mdcheck_start.
mdcheck_start will ensure that mdcheck_continue is active.
Howver if you reboot after a check has started, but before it finishes,
then mdcheck_continue won't cause it to continue, because nothing
starts it on boot.
So add an install option for mdcheck_contine, and make sure it
gets enabled when mdcheck_start is enabled.
Removed checks which limited second volume size only to max value (the
largest size that fits on all current drives). It is now permitted
to create second volume with size lower then maximum possible.
Signed-off-by: Krzysztof Smolinski <krzysztof.smolinski@intel.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Mariusz Tkaczyk [Fri, 4 Oct 2019 10:07:28 +0000 (12:07 +0200)]
imsm: save current_vol number
The imsm container_content routine will set curr_volume index in super
for getting volume information. This flag has never been restored to
original value, later other function may rely on it.
There is a bug in udev (which will hopefully get fixed, but
we should allow for it anways).
When reading a sysfs attribute, it first reads the whole
value of the attribute, then reads again expecting to get
a read of 0 bytes, like you would with an ordinary file.
If the sysfs attribute changed between these two reads, it can
get a mixture of two values.
In particular, if it reads when 'array_state' is changing from
'clear' to 'inactive', it can find the value as "clear\nve".
This causes the test for "|clear|active" to fail, so systemd is allowed
to think that the array is ready - when it isn't.
So change the pattern to allow for this but adding a wildcard at
the end.
Also don't allow for an empty string - reading array_state will
never return an empty string - if it exists at all, it will be
non-empty.
Xiao Ni [Mon, 30 Sep 2019 11:47:59 +0000 (19:47 +0800)]
Init devlist as an array
devlist is an string. It will change to an array if there is disk that
is sbd disk. If one device is sbd, it runs devlist=().
This line code changes devlist from a string to an array. If there is
no sbd device, it can't run this line code. So it will still be a string.
The later codes need an array, rather than an string. So init devlist
as an array to fix this problem.
Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
The code path for metadata 0.90 calls a common routine
fname_from_uuid that uses metadata 1.2. The code expects member
swapuuid to be setup and usable. But it is only setup when using
metadata 1.2. Since the metadata 0.90 did not create swapuuid
and set it. The test (st->ss == &super1) ? 1 : st->ss->swapuuid
fails. The swapuuid is set at compile time based on byte order.
Any call based on metadata 0.90 and on big endian processors,
the --export uuid will be incorrect.
mdadm: Introduce new array state 'broken' for raid0/linear
Currently if a md raid0/linear array gets one or more members removed while
being mounted, kernel keeps showing state 'clean' in the 'array_state'
sysfs attribute. Despite udev signaling the member device is gone, 'mdadm'
cannot issue the STOP_ARRAY ioctl successfully, given the array is mounted.
Nothing else hints that something is wrong (except that the removed devices
don't show properly in the output of mdadm 'detail' command). There is no
other property to be checked, and if user is not performing reads/writes
to the array, even kernel log is quiet and doesn't give a clue about the
missing member.
This patch is the mdadm counterpart of kernel new array state 'broken'.
The 'broken' state mimics the state 'clean' in every aspect, being useful
only to distinguish if an array has some member missing. All necessary
paths in mdadm were changed to deal with 'broken' state, and in case the
tool runs in a kernel that is not updated, it'll work normally, i.e., it
doesn't require the 'broken' state in order to work.
Also, this patch changes the way the array state is showed in the 'detail'
command (for raid0/linear only) - now it takes the 'array_state' sysfs
attribute into account instead of only rely in the MD_SB_CLEAN flag.
Cc: Jes Sorensen <jes.sorensen@gmail.com> Cc: NeilBrown <neilb@suse.de> Cc: Song Liu <songliubraving@fb.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
mdadm: check value returned by snprintf against errors
GCC 8 checks possible truncation during snprintf more strictly
than GCC 7 which result in compilation errors. To fix this
problem checking result of snprintf against errors has been added.
Signed-off-by: Krzysztof Smolinski <krzysztof.smolinski@intel.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
When member drive fails, managemon prepares metadata update and adds
the drive to disk_mgmt_list with DISK_REMOVE flag. It fills only
minor and major. It is enough to recognize the device later.
Monitor thread while processing this update will remove the drive from
super only if it is a spare. It never removes failed member from
disks list. As a result, it still keeps opened descriptor to
non-existing device.
If removed drive is not a spare fill fd in disk_cfg structure
(prepared by managemon), monitor will close fd during freeing it.
Also set this drive fd to -1 in super to avoid double closing because
monitor will close the fd (if needed) while replacing removed drive
in array.
Coly Li [Wed, 31 Jul 2019 05:29:30 +0000 (13:29 +0800)]
udev: add --no-devices option for calling 'mdadm --detail'
When creating symlink of a md raid device, the detailed information of
component disks are unnecessary for rule udev-md-raid-arrays.rules. For
md raid devices with huge number of component disks (e.g. 1500 DASD
disks), the detail information of component devices can be very large
and exceed udev monitor's on-stack message buffer.
This patch adds '--no-devices' option when calling mdadm by,
IMPORT{program}="BINDIR/mdadm --detail --no-devices --export $devnode"
Now the detailed output won't include component disks information,
and the error message "invalid message length" reported by systemd can
be removed.
Coly Li [Wed, 31 Jul 2019 05:29:29 +0000 (13:29 +0800)]
mdadm: add --no-devices to avoid component devices detail information
When people assemble a md raid device with a large number of
component deivces (e.g. 1500 DASD disks), the raid device detail
information generated by 'mdadm --detail --export $devnode' is very
large. It is because the detail information contains information of
all the component disks (even the missing/failed ones).
In such condition, when udev-md-raid-arrays.rules is triggered and
internally calls "mdadm --detail --no-devices --export $devnode",
user may observe systemd error message ""invalid message length". It
is because the following on-stack raw message buffer in systemd code
is not big enough,
systemd/src/libudev/libudev-monitor.c
_public_ struct udev_device *udev_monito ...
struct ucred *cred;
union {
struct udev_monitor_netlink_header nlh;
char raw[8192];
} buf;
Even change size of raw[] from 8KB to larger size, it may still be not
enough for detail message of a md raid device with much larger number of
component devices.
To fix this problem, an extra option '--no-devices' is added (the
original idea is proposed by Neil Brown). When printing detailed
information of a md raid device, if '--no-devices' is specified, then
all component devices information will not be printed, then the output
message size can be restricted to a small number, even with the systemd
only has 8KB on-disk raw buffer, the md raid array udev rules can work
correctly without failure message.
Baruch Siach [Tue, 6 Aug 2019 13:05:23 +0000 (16:05 +0300)]
mdadm.h: include sysmacros.h unconditionally
musl libc now also requires sys/sysmacros.h for the major/minor macros.
All supported libc implementations carry sys/sysmacros.h, including
diet-libc, klibc, and uclibc-ng.
mdadm: load default sysfs attributes after assemblation
Added new type of line to mdadm.conf which allows to specify values of
sysfs attributes for MD devices that should be loaded after the array is
assembled. Each line is interpreted as list of structures containing
sysname of MD device (md126 etc.) and list of sysfs attributes and their
values.
Roman Sobanski [Tue, 2 Jul 2019 11:29:27 +0000 (13:29 +0200)]
Enable probe_roms to scan more than 6 roms.
In some cases if more than 6 oroms exist, resource for particular
controller may not be found. Change method for storing
adapter_rom_resources from array to list.
Signed-off-by: Roman Sobanski <roman.sobanski@intel.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
mdmon: fix wrong array state when disk fails during mdmon startup
If a member drive disappears and is set faulty by the kernel during
mdmon startup, after ss->load_container() but before manage_new(), mdmon
will try to readd the faulty drive to the array and start rebuilding.
Metadata on the active drive is updated, but the faulty drive is not
removed from the array and is left in a "blocked" state and any write
request to the array will block. If the faulty drive reappears in the
system e.g. after a reboot, the array will not assemble because metadata
on the drives will be incompatible (at least on imsm).
Fix this by adding a new option for sysfs_read(): "GET_DEVS_ALL". This
is an extension for the "GET_DEVS" option and causes all member devices
to be returned, even if the associated block device has been removed.
Use this option in manage_new() to include the faulty device on the
active_array's devices list. Mdmon will then properly remove the faulty
device from the array and update the metadata to reflect the degraded
state.
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
When passed size is smaller than chunk, mdadm rounds it to 0 but 0 there
means max available space.
Block it for every metadata. Remove the same check from imsm routine.
Pawel Baldysiak [Fri, 8 Mar 2019 11:19:11 +0000 (12:19 +0100)]
imsm: fix spare activation for old matrix arrays
During spare activation get_extents() calculates metadata reserved space based
on smallest active RAID member or it will take the defaults. Since patch 611d9529("imsm: change reserved space to 4MB") default is extended. If array
was created prior that patch, reserved space is smaller. In case of matrix
RAID - spare is activated in each array one-by-one, so it is spare for first
activation, but treated as "active" during second one.
In case of adding spare drive to old matrix RAID with the size the same as
already existing member drive the routine will take the defaults during second
run and mdmon will refuse to rebuild second volume, claiming that the drive
does not have enough free space.
Add parameter to get_extents(), so the during spare activation reserved space
is always based on smallest active drive - even if given drive is already
active in some other array of matrix RAID.
Pawel Baldysiak [Fri, 22 Feb 2019 11:56:27 +0000 (12:56 +0100)]
Assemble: Fix starting array with initial reshape checkpoint
If array was stopped during reshape initialization,
there might be a "0" checkpoint recorded in metadata.
If array with such condition (reshape with position 0)
is passed to kernel - it will refuse to start such array.
Treat such array as normal during assemble, Grow_continue() will
reinitialize and start the reshape.