Allow disk-policy to be computed given the path and
disk type explicitly. This can be used when hunting through
/dev/disk/by-path for something interesting.
Signed-off-by: NeilBrown <neilb@suse.de>
Adding a spare to a group of partitioned devices is quite different
from adding one to an array. So detect which option is worth trying
based on policy and then try one or the other - or possibly both - as
appropriate.
Signed-off-by: NeilBrown <neilb@suse.de>
To support incorpating a new bare device into a collection of arrays -
one partition each - mdadm needs a modest understanding of partition
tables.
The main needs to be able to recognise a partition table on one device
and copy it onto another.
This will be done using pseudo metadata types 'mbr' and 'gpt'.
Signed-off-by: NeilBrown <neilb@suse.de>
If a device is less than 1K, avoid even trying to seek to 1K before
the end.
The seek will fail anyway so this is a fairly cosmetic fix.
Signed-off-by: NeilBrown <neilb@suse.de>
If policy allows act_spare or act_force_spare, -I will add a
bare device as a spare to an appropriate array.
We don't support adding non-bare devices as spares yet.
Signed-off-by: NeilBrown <neilb@suse.de>
When we find a device that was recently part of the array but is now
out of date (based on the event count) we might want to add it back in
(like --re-add) if the likely cause was a connection problem or we
might not if the likely cause was device failure.
So make this a policy issue: if action=re-add or better, try to re-add
any device that looks like it might be part of the array.
This applies:
when we assemble the array: old devices will be evicted by the
kernel and need to be re-added.
when we assemble the array during --incr for the same reason.
when we find a device that could be added to a running array.
This doesn't affect arrays with external metadata at all.
For such arrays:
When the container is assembled, the most recent instance of each
device is included without reference to whether it is too old or not.
Then the metadata handler must which slices of which devices to
include in which array and with what state. So the
->container_content should probably check the policy and compare the
sequence numbers/event counts.
When a device is added (--add) to a container with active arrays
we only add as a 'spare'. --re-add doesn't seem to be an option.
When a device is added with -I ->container_content gets another
chance to assess things again. So again it should check the policy.
Signed-off-by: NeilBrown <neilb@suse.de>
A device can be in a number of domains.
The domains of an array is the union of the domains of all devices.
A device is allowed to join an array when its set of domains is a
subset of the array's domains.
Signed-off-by: NeilBrown <neilb@suse.de>
Policy can be stated as lines in mdadm.conf like:
POLICY type=disk path=pci-0000:00:1f.2-* action=ignore domain=onboard
This defines two distinct policies which apply to any disk (but not
partition) device reached through the pci device 0000:00:1f.2.
The policies are "action=ignore" which means certain actions will
ignore the device, and "domain=onboard" which means all such devices
as treated as being united under the name 'onboard'.
This patch just adds data structures and code to read and
manipulate them. Future patches will actually use them.
Signed-off-by: NeilBrown <neilb@suse.de>
If udev is not in use, we create device in /dev when assembling
arrays and remove them when stopping the array.
However it may not always be correct to remove the device. If
the array was started with kernel auto-detect, them mdadm didn't
create anything and so shouldn't remove anything.
We don't record whether we created things, so just don't remove
anything with a 'standard' name. Only remove symlinks to the
standard name as we almost certainly created those.
Reported-by: Petre Rodan <petre.rodan@avira.com>
Signed-off-by: NeilBrown <neilb@suse.de>
/dev could be read-only in which case we cannot make devices
there.
So dev_open should first try to use an existing device name,
and if that doesn't work try creating a node in /dev or /tmp.
Reported-by: Paweł Sikora <pluto@agmk.net>
Signed-off-by: NeilBrown <neilb@suse.de>
Commit 3a6ec29ad5 stopped us from adding apparently-working devices
to an active array with --incremental as there is a good chance that they
are actually old/failed devices.
Unfortunately it also stopped spares from being added to an active
array, which is wrong. This patch refines the test to be more
careful.
Reported-by: <fibreraid@gmail.com>
Analysed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Commit 3288b419 (Revert "Incremental: honor --no-degraded to delay assembly")
killed the --no-degraded flag since commit 97b4d0e9 (Incremental: honor
an 'enough' flag from external handlers) made this the default behavior
of -I, and brought -I usage for external/container formats in line with
native metadata. However, this breaks existing usages of '-I
--no-degraded', so allow it as a deprecated option.
Starting a degraded container, like the native metadata case, requires -R.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Ignacy Kasperowicz <ignacy.kasperowicz@intel.com>
Commit 97b4d0e9 "Incremental: honor an 'enough' flag from external
handlers" introduced a regression in that it changed the error return
code for successful invocations.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Ignacy Kasperowicz <ignacy.kasperowicz@intel.com>
Having multiple possible locations and guessing where best to put the
file is too messy, confusing and makes locking problematic.
So just keep it in /dev/.mdadm/map. It is a horrible place but it is
really all we have. System integrators can change this easily at
build time.
Signed-off-by: NeilBrown <neilb@suse.de>
nr_disks is just wrong here - the arrays need room for all disk slots,
even if some are empty, plus spares, plus a possible backup file.
So raid_disks is correct.
Signed-off-by: NeilBrown <neilb@suse.de>
There 'rv' tests were confused and sometimes wrong.
This resulted in not writing the second bsb.
Also fix the test script so the the critical section is long enough
that we have some hope of interrupting it.
Signed-off-by: NeilBrown <neilb@suse.de>
The loop for loading it was hard to follow, so restructure that
and avoid a theoretical use-before-set error.
Also there was a second 'info' structure which hid the first and was
pointless.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'container_enough' changes fliped the default from assembling
an array as soon as we possibly could, to assembling only when all
expected devices are present.
This broken 09imsm-assemble which expects the original default.
So change from "-I" to "-IR" to restore the expected behaviour.
Signed-off-by: NeilBrown <neilb@suse.de>
The container_enough code change broke ddf as ddf never claimed
'enough' devices. So change it to always claim 'enough' to
restore previous behaviour.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ and extra local var was declared, which causes rv setting
to be lost
2/ a -ve rv was left -ve while we should be return 1 on err.
Signed-off-by: NeilBrown <neilb@suse.de>
- Update the comments
- use some defined names instead of magic numbers.
- restore /var/run/mdadm/map to have priority over /dev/.mdadm/map
Signed-off-by: NeilBrown <neilb@suse.de>
It turns out that /lib/init/rw doesn't exist in early boot
like I thought. So give up on that idea and just use
/dev/.mdadm/ for files that must persist from early-boot
to regular boot.
Signed-off-by: NeilBrown <neilb@suse.de>
While we attempt to use a lockfile to grant exclusive access to the
mapfile, our implementation is buggy. Specifically, we create a lockfile,
then lock it, at which point new instances can open the lockfile and
attempt to lock it, which will cause them to block. However, when we are
ready to unlock it, we unlink the file. This causes existing lock waiters
to get a lock on an unlinked inode while a different instance may now
create a new lockfile and get an exclusive lock on it.
There are several possible fixes. The chosen one is to test if
->s_nlink is zero after we get the lock and to retry if it isn't.
This means:
- failing to unlink a file doesn't leave a stale lock
- we can block waiting to get a lock rather than busy-waiting
- we don't need to leave a lock file permanently in place.
Reported-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The watch option to udev tells udev to watch our mdadm device file for
close events and on a close it rechecks the device. This means that if,
for example, we use mdadm to --grow the array from a 4 disk to 5 disk
array, when mdadm closes the array, udev will re-read the superblock and
update its internal database with the new information. This can also be
used to cause udev to create new device special files if, for example, a
partitioning program is used to modify the partition table on the actual
md device and that program does not call the syscall to reread the
partition table.
Signed-off-by: Doug Ledford <dledford@redhat.com>
One: a single character typo (of instead of or in an error printout)
Two: Audited usage of tfd file descriptor. Make sure that the tfd file
is always closed after usage, and that the tfd variable is reset to -1
if we are going to continue in our loop (not necessary if we know we
will return from our function without going through the dv loop again).
Signed-off-by: Doug Ledford <dledford@redhat.com>
We now have 3 directory definitions: mdmon directory for its pid and
sock files (compile time define, not changable at run time), mdmonitor
directory which is for the mdadm monitor mode pid file (can only be
passed in via command line at the time mdadm is invoked in monitor mode),
and the directory for the mdadm incremental assembly map file (compile
time define, not changable at run time). Only the mdadm map file still
hunts multiple locations, and the number of locations has been reduced
to /var/run and the compile time specified location. Re-use of similar
sounding defines that actually didn't denote their actual usage at
compile time made it more difficult for a person to know what affect
changing the compile time defines would have on the resulting programs.
This patch renames the various defines to clearly identify which item
the define affects. It also reduces the number of various directories
which will be searched for these files as this has lead to confusion
in mdadm and mdmon in terms of which files should take precedence when
files exist in multiple locations, etc. It's best if the person
compiling the program intentionally and with planning selects the
right directories to be used for the various purposes. Which directory
is right depends on which items you are talking about and what boot
loader your system uses and what initramfs generation program your
system uses. Because of the inter-dependency of all these items it
would typically be up to the distribution that mdadm is being integrated
into to select the correct values for these defines.
Signed-off-by: Doug Ledford <dledford@redhat.com>
This number isn't meaningful for RAID0 as a different amount of space
might be used from each device.
It isn't meaningful for linear either, but already was not reported
for linear.
Detail doesn't report it either.
So make --examine not report it.
Signed-off-by: NeilBrown <neilb@suse.de>
Reported-by: Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE>
When left-shifting we must be sure that the value being
shifted is large enough to not lose bits.
The 'chunkssize' in CreateBitmap is only 'long' so it
can overflow. So cast to 'long long' first.
Also fix a similar issue in Detail even though it isn't currently
being compiled.
Signed-off-by: NeilBrown <neilb@suse.de>
Reported-by: Tomasz Chmielewski <mangoo@wpkg.org>
GET_ARRAY_INFO always succeeds on an inactive container, so we need to
be a bit more diligent about adding a disk to an active container.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The 4K superblock can be as close as 64K from the end
of the device. As the bitmap (with header) lives after
the superblock (with 0.90 metadata) there could be as
little as 60K of space.
So limit the bitmaps to 59.5K, and only write 60K including
the header.
The bug fixed here means that bitmaps cannot be created
on devices which are exact multiples of 64K in size
Signed-off-by: NeilBrown <neilb@suse.de>
super-intel.c: In function ‘imsm_add_spare’:
super-intel.c:4833: error: ‘array_start’ may be used uninitialized in this function
super-intel.c:4834: error: ‘array_end’ may be used uninitialized in this function
This is valid, if we don't find a spare candidate then array_{start,end}
will be uninitialized.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>