map_num() returns NULL if key is not defined. This patch adds
alternative, non NULL version for cases where NULL is not expected.
There are many printf() calls where map_num() is called on variable
without NULL verification. It works, even if NULL is passed because
gcc is able to ignore NULL argument quietly but the behavior is
undefined. For safety reasons such usages will use map_num_s() now.
It is a potential point of regression.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
The test case is:
1. create one imsm container
2. create a raid5 device from the container
3. unplug two disks
4. mdadm --detail /dev/md126
[root@rhel85 ~]# mdadm -D /dev/md126
/dev/md126:
Container : ��, member 0
The Detail function first gets container name by function
map_dev_preferred. Then it tries to find which disks are
available. In patch db5377883fef(It should be FAILED..)
uses map_dev_preferred to find which disks are under /dev.
But now, the major/minor information comes from kernel space.
map_dev_preferred malloc memory and init a device list when
first be called by Detail. It can't find the device in the
list by the major/minor. It free the memory and reinit the
list.
The container name now points to an area tha has been freed.
So the containt is a mess.
This patch replaces map_dev_preferred with access.
Fixes: db5377883f (It should be FAILED when raid has)
Signed-off-by: Xiao Ni <xni@redhat.com>
Reported-by: Fine Fan <ffan@redhat.com>
Acked-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Arrays with external metadata do not have spare disks directly
assigned to volumes; spare disks belong to containers and are
moved to arrays when the array is degraded/reshaping.
Thus, the display of zero spare disks in volume details is
incorrect and can be confusing.
Signed-off-by: Oleksandr Shchirskyi <oleksandr.shchirskyi@linux.intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
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>
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.
Signed-off-by: Zhao Heming <heming.zhao@suse.com>
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: 64bf4dff34 (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>
On the node with /proc/mdstat is
Personalities : [raid1]
md0 : active raid1 sdb[4] sdc[3] sdd[2]
1046528 blocks super 1.2 [3/2] [UU_]
recover=REMOTE
bitmap: 1/1 pages [4KB], 65536KB chunk
Let's change the 'State' of 'mdadm -Q -D' accordingly
State : clean, degraded
With this patch, it will be
State : clean, degraded, recovering (REMOTE)
Signed-off-by: Lidong Zhong <lidong.zhong@suse.com>
Acked-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
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.
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
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.
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
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>
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.
Signed-off-by: Coly Li <colyli@suse.de>
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
'Commit b9c9bd9bac ("Detail: ensure --export names are acceptable as
shell variables")' duplicates mdi->sys_name to sysdev string by,
char *sysdev = xstrdup(mdi->sys_name + 1);
which skips the first character of mdi->sys_name. Then when running
mdadm --detail <md device> --export, the output looks like,
MD_DEVICE_ev_sda2_ROLE=1
MD_DEVICE_ev_sda2_DEV=/dev/sda2
The first character of md device (between MD_DEVICE and _ROLE/_DEV)
is dropped. The expected output should be,
MD_DEVICE_dev_sda2_ROLE=1
MD_DEVICE_dev_sda2_DEV=/dev/sda2
This patch removes the '+ 1' from calling xstrdup() in Detail(), which
gets the dropped first character back.
Reported-by: Arvin Schnell <aschnell@suse.com>
Fixes: b9c9bd9bac ("Detail: ensure --export names are acceptable as 4 shell variables")
Signed-off-by: Coly Li <colyli@suse.de>
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
1. There are some places which didn't free map as
discovered by coverity.
CID 289661 (#1 of 1): Resource leak (RESOURCE_LEAK)12. leaked_storage: Variable mapl going out of scope leaks the storage it points to.
CID 289619 (#3 of 3): Resource leak (RESOURCE_LEAK)63. leaked_storage: Variable map going out of scope leaks the storage it points to.
CID 289618 (#1 of 1): Resource leak (RESOURCE_LEAK)26. leaked_storage: Variable map going out of scope leaks the storage it points to.
CID 289607 (#1 of 1): Resource leak (RESOURCE_LEAK)41. leaked_storage: Variable map going out of scope leaks the storage it points to.
2. If we call map_by_* inside a loop, then map_free
should be called in the same loop, and it is better
to set map to NULL after free.
3. And map_unlock is always called with map_lock,
if we don't call map_remove before map_unlock,
then the memory (allocated by map_lock -> map_read
-> map_add -> xmalloc) could be leaked. So we
need to free it in map_unlock as well.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
e->percent access the mdstat_ent which was already freed in free_mdstat
Signed-off-by: Zhipeng Xie <xiezhipeng1@huawei.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Containers used to be handled as active arrays because GET_ARRAY_INFO
ioctl returns valid structure for them. As containers appear as inactive
in sysfs, the output for detail command has changed.
Stop relying on inactive state for containers. Make the output look the
same as in mdadm 4.0.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
The check for inactive array is incorrect as it compares it against
active array. Introduce a new function md_is_array_active so the check
is consistent across the code.
As the output contains list of disks in the array include this
information in sysfs read.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
When GET_ARRAY_INFO ioctl is successful, mdadm exits with an error.
It breaks udev and no links in /dev/md are created.
Also change debug print to error print in the message indicating lack
of the link to facilitate debugging similar issues in the future.
Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
While sysfs support will hopefully go away eventually, lets not break
it unnecessarily for now.
Fixes: 901d5ee ("Detail: Stop bothering about md drivers older than 0.90.00")
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
This is easily obtained from sysfs as part of the existing call to
sysfs_read() and it simplifies the code a little too.
Another small step in the process of getting rid of the GET_ARRAY_STATE
ioctl.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
If an array contains a device which has a name that
contains something other than alphnumerics and underscores,
then some values reported by "mdadm --detail --export" will
not be valid as variable assignment of the shell.
This particularly affects dm devices.
e.g.
MD_DEVICE_dm-4_ROLE=1
MD_DEVICE_dm-4_DEV=/dev/dm-4
As it is particularly useful to be able to work with these
in a shell script, and as the precise name is not important,
change all non-alphanumerics to '_'.
MD_DEVICE_dm_4_ROLE=1
MD_DEVICE_dm_4_DEV=/dev/dm-4
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
This removes all the inline ioctl calls for GET_DISK_INFO, allowing us
to switch to sysfs in one place, and improves type checking.
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Remove most direct ioctl calls for GET_ARRAY_INFO, except for one,
which will be addressed in the next patch.
This is the start of the effort to clean up the use of ioctl calls and
introduce a more structured API, which will use sysfs and fall back to
ioctl for backup.
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Show the currently enabled consistency policy in the output from
--detail. Add 3 spaces to all existing items in Detail output to align
with "Consistency Policy : ".
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
If you call "mdadm --detail" with a device file for an array which
doesn't exist, such as by
mknod /dev/md57 b 9 57
mdadm --detail /dev/md57
you get an unhelpful message about and inactive RAID0, and return
status is '0'. This is confusing.
So catch this possibility and print a more useful message, and
return a non-zero status.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
In Detail.c the buffer path in function Detail is defined as path[200],
in fact the max lenth of content which needs to write to the buffer is
287. Because the length of dname of struct dirent is 255.
During building it reports error:
error: ‘%s’ directive writing up to 255 bytes into a region of size 189
[-Werror=format-overflow=]
In function examine_super0 there is a buffer nb with length 5.
But it need to show a int type argument. The lenght of max
number of int is 10. So the buffer length should be 11.
In human_size function the length of buf is 30. During building
there is a error:
output between 20 and 47 bytes into a destination of size 30.
Change the length to 47.
Signed-off-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Allow per-device "failfast" flag to be set when creating an
array or adding devices to an array.
When re-adding a device which had the failfast flag, it can be removed
using --nofailfast.
failfast status is printed in --detail and --examine output.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
When there is failed HDDs, journal device showed in wrong place
of --detail:
Number Major Minor RaidDevice State
4 8 24 - journal /dev/sdb8
1 8 18 1 active sync /dev/sdb2
2 8 19 2 active sync /dev/sdb3
3 8 21 3 active sync /dev/sdb5
0 8 17 - faulty /dev/sdb1
This patch fixed the output as:
Number Major Minor RaidDevice State
- 0 0 0 removed
1 8 18 1 active sync /dev/sdb2
2 8 19 2 active sync /dev/sdb3
3 8 21 3 active sync /dev/sdb5
0 8 17 - faulty /dev/sdb1
4 8 24 - journal /dev/sdb8
Reported-by: Yi Zhang <yizhan@redhat.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Commit 4dd2df0966 added a trip through makedev(), major(), and minor() for
device major and minor numbers. This would cause mdadm to fail in operating
on a device with a minor number bigger than (2^19)-1 due to it changing
from dev_t to a signed int and back.
Where this was found as a problem was when a array was created with a device
specified as a name like /dev/md/raidname and there were already 128 arrays
on the system. In this case, mdadm would chose 1048575 ((2^20)-1) for the
array and minor number. This would cause the major and minor number to become
negative when generated from devnm2devid() and passed to major() and minor()
in open_dev_excl(). open_dev_excl() would then call dev_open() which would
detect the negative minor number and call open() on the *char containing the
major:minor pair which isn't a valid file.
Signed-off-by: Mike Lovell <mlovell@bluehost.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
This adds a buffer size argument to load_sys(), rather than relying on
a hard coded buffer size. The old behavior was safe because we knew
the kernel would never return strings overrunning the buffers, however
it was ugly, and would cause code checking tools to spit out warnings.
This caused a Coverity warning over the read into
sra->sysfs_array_state which is only 20 bytes.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
v0.90 metadata can handle devices between 2GB and 4GB, but we need
to treat the 'size' and unsigned. In a couple of places we don't.
URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809447
Signed-off-by: NeilBrown <neilb@suse.com>
Now that we can print device details with a specific raid_disk but not
disk.number, the condition for "print either disk.number or disk.raid_disk"
must be make more specific.
Reported-by: Coly Li <colyli@suse.com>
Signed-off-by: NeilBrown <neilb@suse.com>
As we give journal device raid_disk of 0, the output of --detail is:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
5 8 24 0 journal /dev/sdb8
1 8 18 1 active sync /dev/sdb2
2 8 19 2 active sync /dev/sdb3
3 8 21 3 active sync /dev/sdb5
4 8 23 - spare /dev/sdb7
This patch makes it back to:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 18 1 active sync /dev/sdb2
2 8 19 2 active sync /dev/sdb3
3 8 21 3 active sync /dev/sdb5
4 8 23 - spare /dev/sdb7
5 8 24 - journal /dev/sdb8
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.com>
When a particular raid-disk is missing, we don't know which disk number
it should have, and reporting a number could result in duplicate
numbers (with v1.x metadata - never with the old 0.90).
So set the default to -1 and recoginise that when printing.
Signed-off-by: NeilBrown <neilb@suse.com>
Back in
Commit: 8057db46a1 ("Detail: fix handling of 'disks' array.")
when we doubled the size of the 'disks' array to handle primary and
replacement, we should have halved the setting of the default raid_disk
number.
Reported-by: Coly Li <colyli@suse.de>
Signed-off-by: NeilBrown <neilb@suse.com>
Since the introduction of replacement devices, we reserve
to places in the "disks" array for each raid disk.
That means we should allocate to twice "max_disk" as the array
could have that many raid_disks (though that would limit the
number of replacements).
A couple of other places need to use "max_disks*2" instead of
"max_disks" to co-ordinate with this.
Reported-by: Or Sagi <ors@reduxio.com>
Signed-off-by: NeilBrown <neilb@suse.de>
dm devices which only have a single underlying md device
will respond to md ioctls as though they were that md device.
This can confuse mdadm and lead it to violating its segments.
So add tests for NULL where appropriate. You might not get exactly
the right answer when you "mdadm -D" a dm device, but at least it won't
crash now.
Reported-by: Willy Weisz <Willy.Weisz@univie.ac.at>
Resolves: https://bugzilla.novell.com/show_bug.cgi?id=887821
Signed-off-by: NeilBrown <neilb@suse.de>
Have mdadm --Detail --brief --verbose print the list of devices in
alphabetical order.
This is useful for debugging purposes. E.g. the test script
10ddf-create compares the output of two mdadm -Dbv calls which
may be different if the order is not deterministic.
(I confess: I use a modified "test" script that always runs
"mdadm --verbose" rather than "mdadm --quiet", otherwise this
wouldn't happen in 10ddf-create).
Signed-off-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
Mariusz Tkaczyk
Xiao Ni
Mateusz Grzonka
Oleksandr Shchirskyi
Zhao Heming
Lidong Zhong
NeilBrown
Blazej Kucman
Guilherme G. Piccoli
Coly Li
Guoqing Jiang
Zhipeng Xie
Mariusz Tkaczyk
Tomasz Majchrzak
Jes Sorensen
NeilBrown
Jes Sorensen
Artur Paszkiewicz
Song Liu
Mike Lovell
Jes Sorensen
Constantine Shulyupin
Martin Wilck