NeilBrown [Tue, 15 Mar 2011 03:51:12 +0000 (14:51 +1100)]
managemon: Don't do spare assignment while any updates are pending.
Spare assignment requires full knowledge of array state. A pending
update might modify that state (such as a pending spare assignment)
so don't try while there are updates pending.
NeilBrown [Tue, 15 Mar 2011 03:48:20 +0000 (14:48 +1100)]
Manage/external: for external metadata, add_to_super needs lock on container.
add_to_super could use information from the current superblock (ddf
does), so add_to_super for external metadata should be called with
the O_EXCL lock held on the container to ensure the update is complete
before any other process tries to make any changes (like adding
another device to array).
NeilBrown [Mon, 22 Nov 2010 08:35:25 +0000 (19:35 +1100)]
Manage: be more careful about --add attempts.
If an --add is requested and a re-add looks promising but fails or
cannot possibly succeed, then don't try the add. This avoids
inadvertently turning devices into spares when an array is failed but
the devices seem to actually work.
NeilBrown [Tue, 30 Nov 2010 05:34:25 +0000 (16:34 +1100)]
Grow: give useful message when adding bitmap gives EBUSY.
If adding a bitmap fails with EBUSY, then it is because the array is
currently resyncing/recovering/reshaping.
As this is non-obvious, give a message explaining the fact.
NeilBrown [Wed, 1 Dec 2010 03:51:27 +0000 (14:51 +1100)]
Create/grow: improve checks on number of devices.
Check on upper limit of number of devices was in the wrong place.
Result was could not create array with more than 27 devices without
explicitly setting metadata, even though default metadata allows more.
Fixed, and also perform check when growing an array.
Krzysztof Wojcik [Thu, 10 Mar 2011 06:07:04 +0000 (17:07 +1100)]
FIX: Reset disk state if disk is missing
If we can't read actual disk state, it shoud be initiated
to 0.
Overwise it may be out of date value resulting false action
later in code (e.g. set disk to improper state).
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Thu, 10 Mar 2011 00:41:21 +0000 (11:41 +1100)]
dev_open should always open read-only.
When opening an array to manipulate it we never need to write to the
array and sometimes it might be read-only so the open for write will
fail.
So always open read-only.
Reported-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Mon, 21 Feb 2011 00:41:01 +0000 (11:41 +1100)]
Teach --assemble --force to handle reshapes a little better.
When we force-assemble an array which is in the middle of a reshape,
we should repeat the reshape of any parts that aren't recorded in
the oldest superblock.
This is unlikely to make a significant difference, but could make
a small difference, and is safer.
NeilBrown [Mon, 14 Feb 2011 23:45:01 +0000 (10:45 +1100)]
Fix regression with removing 'failed' and 'detached' devices.
If a request to remove all 'failed' or 'detached' devices chooses to
remove the first device, it will not actually try the removal and will
skip any following devices.
...and need the second '/' from the end of the string to read detect a
'md' device.
Reported-by: Krzysztof Wasilewski <krzysztof.wasilewski@intel.com> Cc: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
Luca Berra [Sun, 12 Dec 2010 10:33:55 +0000 (11:33 +0100)]
segfault in imsm create with wrong arguments
When calling mdadm -C --metadata=imsm -l 1 /dev/sd..
mdadm segfaults in default_chunk_imsm()
above syntax is incorrect, but mdadm should error instead of segfaulting
John Robinson [Wed, 3 Nov 2010 03:08:00 +0000 (23:08 -0400)]
mdadm.8: man page improvements concerning reshape and metadata types.
- other differences between 0.90 and 1.x metadata explained
- reshape text enhanced to properly acknowledge shrinks and in-place
reshapes, particularly in the context of --backup-file.
Fix byte-order conversion in update_super1("assemble")
This code is wrong is several ways, and failed on big-endian machines.
Put in correct endian coversions: 'want' is cpu-order, dev_roles[] is little-endian,
16 bit.
Reported-by: Doug Nazar <nazard.michi@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Tue, 31 Aug 2010 05:21:40 +0000 (15:21 +1000)]
Don't remove md devices with standard names.
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.
NeilBrown [Sun, 29 Aug 2010 22:48:48 +0000 (08:48 +1000)]
Allow dev_open to work on read-only /dev
/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>
NeilBrown [Thu, 12 Aug 2010 01:41:41 +0000 (11:41 +1000)]
Allow --incremental to add spares to an array.
Commit 3a6ec29ad56 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>
Dan Williams [Mon, 9 Aug 2010 17:26:24 +0000 (10:26 -0700)]
Incremental: accept '--no-degraded' as a deprecated option
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>
Dan Williams [Tue, 10 Aug 2010 15:44:45 +0000 (08:44 -0700)]
Incremental: return success in 'container not enough' case
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>
NeilBrown [Fri, 6 Aug 2010 04:40:53 +0000 (14:40 +1000)]
Grow: use raid_disks, not nr_disks
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.
NeilBrown [Thu, 5 Aug 2010 01:44:26 +0000 (11:44 +1000)]
Fix test for imsm prodigal member scenario
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.
Switch from /lib/init/rw to /dev for early-boot files.
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.
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.
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.
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).
Fix all the confusion over directories once and for all.
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.
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>
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
Dan Williams [Tue, 6 Jul 2010 19:48:59 +0000 (12:48 -0700)]
imsm: fix a -O2 build warning
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>
Dan Williams [Tue, 6 Jul 2010 19:48:56 +0000 (12:48 -0700)]
mdmon: satisfy glibc tls abi requirements with pthreads
Setting up a proper tls descriptor is required to conform to the abi
[1]. Until it can be implemented in mdmon use pthreads instead of
clone(2) to let glibc handle the details. The old behaviour can be had
by un-defining USE_PTHREADS.
Note, the "O2" builds need LDFLAGS now to pick up the '-pthread' option.
[1]: http://people.redhat.com/drepper/tls.pdf
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Marcin Labun [Tue, 6 Jul 2010 07:49:37 +0000 (17:49 +1000)]
Fix the count of member devices in mdstat_read function.
Correction of the number of container or volume member devices (devcnt
in struct mdstat_ent). The number after the last devices was counted
towards member of devices.
Signed-off-by: Marcin Labun <marcin.labun@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
--test can be given in Manage mode.
This can be used when there is an attempt to fail or remove 'faulty',
'failed' or 'detached' devices, or to re-add 'missing' devices.
If no devices were failed, removed, or re-added, then mdadm will
exit with status '2'.
If the device name "missing" is given for --re-add, then mdadm will
attempt to find any device which should be a member of the array but
currently isn't and will --re-add it to the array.
This can be useful if a device disappeared due to a cabling problem,
and was then re-connected.
The appropriate sequence would be
mdadm /dev/mdX --fail detached
mdadm /dev/mdX --remove detached
mdadm /dev/mdX --re-add missing
Don't let incremental add devices to active arrays.
Adding devices to active arrays in --incremental is a bit dubious.
Normally the array won't be activated until all expected devices are
present, so this situation would mean that the given device is not
expected, so is probably failed. In that case it should only be added
by explicit sysadmin request.
However if --run was given, then quite possibly the array was
assembled earlier when not complete, so it is less clear whether it is
wrong to add this device or not. In that case add it as that is
generally safest.
It would be nice to allow policy for this to be explicitly given by
sysadmin.
Be moving 'load_super" before "conf_test_metadata" we left
tst->sb set even if conf_test_metadata fails, so the device will
actually be accepted and used.
So if we decide to reject the device, free the superblock so it is
clear that it is rejected.
Dan Williams [Fri, 2 Jul 2010 00:28:14 +0000 (17:28 -0700)]
mdmon: prevent allocations due to late binding
Current versions of glibc do not provide a useable interface to clone(2) as it
inflicts hidden dependencies on setting up a glibc specific tls
descriptor. The dynamic linker trips this dependency and causes mdmon
to intermittently fail to load. Resolving all dynamic linking prior to
starting the monitor thread appears to mitigate the issue but there is no
guarantee that another tls dependency will bite us later.
However, while the debate continues with the glibc maintainers it seems
prudent to keep this change. It ensures that we do not get into a
situation where the monitor thread needs to make a late allocation to
resolve a symbol.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
NeilBrown [Wed, 30 Jun 2010 07:20:38 +0000 (17:20 +1000)]
Avoid skipping devices where removing all faulty/detached devices.
When using 0.90 metadata, devices can be renumbered when
earlier devices are removed.
So when iterating all devices looking for 'failed' or 'detached'
devices, we need to re-check the same slot we checked last time
to see if maybe it has a different device now.
Reported-by: Jim Paris <jim@jtan.com>
Resolves-Debian-Bug: 587550 Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Wed, 30 Jun 2010 06:55:17 +0000 (16:55 +1000)]
Update udev rules for hotplug support.
- split the rules for handling components of array to be clearly
separate from rules for handling the arrays themselves.
- add call to "-If" when removing a device
- uncomment the --incremental call when adding a device.
NeilBrown [Wed, 30 Jun 2010 06:55:17 +0000 (16:55 +1000)]
Add mdstat_by_component
This allows finding the array which contains a given component.
Components are named using the kernel-internal string name such
as "sda1" or "hdb".
Don't return member arrays, only the contain that contains them.
Also tidy up the parsing of 'inactive' arrays in /proc/mdstat.
If we see 'inactive' we need to set 'in_devs' immediately as there
is no level coming.
NeilBrown [Wed, 30 Jun 2010 06:52:54 +0000 (16:52 +1000)]
Correct documentation for --rebuild-map
In some places it is referred to as "--rebuild", and while
that works due to getopt allowing prefixes, it could appear
confusing (rebuild means other things too) and being explicit
is some safeguard if we want to add e.g. --rebuild-foo later.
Dan Williams [Tue, 22 Jun 2010 23:30:59 +0000 (16:30 -0700)]
Rename subarray v2
Allow the name of the array stored in the metadata to be updated. In
some cases the metadata format may not be able to support this rename
without modifying the UUID. In these cases the request will be blocked.
Otherwise we allow the rename to take place, even for active arrays.
This assumes that the user understands the difference between the kernel
node name, the device node symlink name, and the metadata specific name.
Anticipating further need to modify subarrays in-place, introduce the
->update_subarray() superswitch method. A future potential use
case is setting storage pool (spare-group) identifiers.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dan Williams [Thu, 17 Jun 2010 00:26:04 +0000 (17:26 -0700)]
Always assume SKIP_GONE_DEVS behaviour and kill the flag
...i.e. GET_DEVS == (GET_DEVS|SKIP_GONE_DEVS)
A null pointer dereference in Incremental.c can be triggered by
replugging a disk while the old name is in use. When mdadm -I is called
on the new disk we fail the call to sysfs_read(). I audited all the
locations that use GET_DEVS and it appears they can tolerate missing a
drive. So just make SKIP_GONE_DEVS the default behaviour.
Also fix up remaining unchecked usages of the sysfs_read() return value.
Reported-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dan Williams [Wed, 16 Jun 2010 01:41:57 +0000 (18:41 -0700)]
Remove 'checkpointing' side effect of --wait-clean
Now that mdmon records periodic checkpoints, and checkpoints every
->set_array_state() event we no longer need to 'idle' sync_action from
--wait-clean.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dan Williams [Wed, 16 Jun 2010 01:41:57 +0000 (18:41 -0700)]
mdmon: record sync_completed directly to the metadata
When sync_action is idle mdmon takes the latest value of md/resync_start
or md/<dev>/recovery_start to record the resync/rebuild checkpoint in
the metadata. However, now that mdmon is reading sync_completed there
is no longer a need to wait for, or force an idle event to take a
checkpoint.
Simply update the forward progress of ->last_checkpoint at every wakeup
event and force it to be recorded at least every 1/16th array-size
interval. It may be recorded more frequently if a ->set_array_state()
event occurs.
This also cleans up some confusion in handling the dual-rebuild case.
If more than one spare has been activated the kernel starts the rebuild
at the lowest recovery offset, so we do not need to worry about
min_recovery_start().
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dave Jiang [Wed, 16 Jun 2010 01:41:53 +0000 (18:41 -0700)]
create: Check with OROM limit before setting default chunk size
Make create check with the appropriate meta data handler and see what the
largest chunk size is supported. The current 512K default is not supported
by existing imsm OROM.
[dan.j.williams@intel.com: trim the upper limit to 512k for future oroms] Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>