In a sufficiently recent kernel, an md%d array can be
created by writing to .../parameters/new_array.
If mdadm does this consistently, then another new
feature, disabling create_on_open, can be enabled.
This avoids races on shutdown.
An added benefit of using new_array (where available)
is that it allows md arrays with numbers larger than 511
(e.g. md999) to be created. The old create_on_open
mechanism doesn't support such devices since
Commit: af5628f05db6 ("md: disable probing for md devices 512 and over.")
in Linux 3.17.
After a few more mdadm releases it would be good to
have mdadm disable create_on_open automatically.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
md_get_array_info() can be used instead of md_get_version() to
determine this is in fact a valid array.
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
There is no need to request write access when opening
the md device, as we never write to it, and none of the
ioctls we use require write access.
If we do open with write access, then when we close, udev notices that
the device was closed after being open for write access, and it
generates a CHANGE event.
This is generally unwanted, and particularly problematic when mdadm is
trying to --stop the array, as the CHANGE event can cause the array to
be re-opened before it completely closed, which results in a new mddev
being allocated.
So just use O_RDONLY instead of O_RDWR.
Reported-by: Marc Smith <marc.smith@mcc.edu>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
The clang compiler complained about each of these.
The mdmon.h error will only affect 'far' RAID10 arrays using intel or DDF
metadata, and there is no such thing.
The mdopen.c will cause a problem if there are no free md device
numbers in the first 512. That is fairly unlikely.
The restripe.c error would only affect the 'test_stripe' command, and
probably doesn't change its behaviour.
The super-intel.c fix is purely cosmetic.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Linux allows for 32 character device names. When using the maximum
size device name and also storing "/dev/", devname needs to be 37
character long to store the complete device name.
i.e. "/dev/md_abcdefghijklmnopqrstuvwxyz12\0"
Signed-off-by: Robert LeBlanc<robert@leblancnet.us>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Newer kernels don't allow for specifying an array larger than 511. This
makes it so find_free_devnm wraps to 511 instead of 2^20 - 1.
Signed-off-by: Mike Lovell <mlovell@bluehost.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>
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>
There is only one called to find_free_devnum and it is in mdopen.c
The removes a dependency between util.c and config.c which allows
us to now drop config.o from mdmon.
Signed-off-by: NeilBrown <neilb@suse.de>
With the 'devnm' infrastructure fixed, it is quite easy to support
names like "md_home" for md arrays.
The currently defaults to "off" and can be enabled in mdadm.conf with
CREATE names=yes
This is incase other tools get confused by the new names.
Signed-off-by: NeilBrown <neilb@suse.de>
We widely use a "devnum" which is 0 or +ve for md%d devices
and -ve for md_d%d devices.
But I want to be able to use md_%s device names.
So get rid of devnum (a number) and use devnm (a 32char string).
eg.
md0
md_d2
md_home
Signed-off-by: NeilBrown <neilb@suse.de>
map_dev can be slow so it is best to not call it when
not necessary.
The final test in "find_free_devnum" is not relevant when
udev is being used, so remove the test in that case.
Signed-off-by: NeilBrown <neilb@suse.de>
Creating a new MD device with the name 'd-0' results in some
unexpected behavior, since mdadm sees that '-0' is a
non-negative integer and therefore makes a "partitionable"
device (/dev/md_d0). This is not the expected behavior,
since the documentation mentions 'dN' several places, and a
reboot brings it up as /dev/md/d-0. Make this consistent
by ensuring that the character immediately following 'd' is
a digit during creation.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ When printing the "name=" entry for --brief output,
enclose name in quotes if it contains spaces etc.
Quotes are already supported for reading mdadm.conf
2/ When a name is used as a device name, translate spaces
and tabs to '_', as well as the current translation of
'/' to '-'.
Signed-off-by: NeilBrown <neilb@suse.de>
malloc should never fail, and if it does it is unlikely
that anything else useful can be done. Best approach is to
abort and let some super-daemon restart.
So define xmalloc, xcalloc, xrealloc, xstrdup which don't
fail but just print a message and exit. Then use those
removing all the tests for failure.
Also replace all "malloc;memset" sequences with 'xcalloc'.
Signed-off-by: NeilBrown <neilb@suse.de>
Silencing gcc's warning of uninitialized variables was hiding a bug
where if we have /dev/md64 as a symlink, and /dev/md64p1 was a real
device node.
In this case major_num and minor_num would not get populated, but we
end up comparing against them because the stat for md64p1 succeeds.
Instead of using the int foo = foo trick, change the code to set
set the variables to invalid values so comparisons will fail.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
As mdadm is normally a short-lived program it isn't always necessary
to free memory that was allocated, as the 'exit()' call will
automatically free everything. But it is more obviously correct if
the 'free' is there.
So this patch add a few calls to 'free'
Signed-off-by: NeilBrown <neilb@suse.de>
If someone creates/assemble an array called "/dev/md0", don't force
it to be "/dev/md/0". Doing so isn't really necessary and it
likely to confuse people.
Signed-off-by: NeilBrown <neilb@suse.de>
When choosing the minor number to use with an array, we currently base
the number of the 'name' stored in the metadata if that name is
numeric.
Extend that so that if it looks like a number md device name (/dev/md0
or just md0 or even /dev/md/0), then we use the number at the end to
suggest a minor number.
The means that if someone creates and array with "--name md0" or even
"--name /dev/md0" it will continue to do what they expect.
Signed-off-by: NeilBrown <neilb@suse.de>
If we need to add digits to a name to make it unique, but don't have
to add '_', we need to avoid adding a digit immediately after a digit.
So if the last character of the name is a digit, add the '_' anyway.
Signed-off-by: NeilBrown <neilb@suse.de>
So if the array with minor number matching the name of a new array
already exists, just assemble with a different minor number.
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than appending the md minor number, we now append a small
sequence number to make sure name in /dev/md/ that aren't LOCAL are
unique. As the map file is locked while we do this, we are sure
of no losing any races.
Signed-off-by: NeilBrown <neilb@suse.de>
This reflect that fact that more often than not it is creating things
in /dev, and allows for a new open_mddev which does just that.
Signed-off-by: NeilBrown <neilb@suse.de>
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>
Fix on call that passed an invalid mode to open
Don't pass a third arg unless we also pass O_CREAT
Use symbolic args for 2nd and 3rd args
Signed-off-by: Doug Ledford <dledford@redhat.com>
From: Bill Nottingham <notting@redhat.com>
mdadm --incremental doesn't really do any locking. If you get multiple
events in parallel for the same device (that has not yet started), they
will all go down the path to create the array. One will succeed, the
rest will have SET_ARRAY_INFO die with -EBUSY (md: array mdX already has disks!)
and will exit without adding the disk.
Original bug report is: https://bugzilla.redhat.com/show_bug.cgi?id=433932
This is solved by adding very very rudimentary locking. Incremental() now
opens the device with O_EXCL to ensure only one invocation is frobbing the
array at once. A simple loop just tries to open 5 times a second for 5
seconds. If the array stays locked that long, you probably have bigger
issues.