Child_monitor was design to perform 'manage_reshape' for native
arrays. So change the signature for ->manage_reshape to match
child_monitor and move the all to the same place that child_monitor
is called from.
Also give super-intel a manage_reshape handler which simple calls
child_monitor.
Signed-off-by: NeilBrown <neilb@suse.de>
child_monitor has overall responsibility for backups using the generic
bsb, so move all handling under it's control.
signed-off-by: NeilBrown <neilb@suse.de>
We currently suspend rather large sections of
the array which can take a while to process.
Possibly smaller sections are better. Possibly it should be
adjusted on a timeout basis.
Signed-off-by: NeilBrown <neilb@suse.de>
The array might not be a multiple of the chosen backup size, so
the last bit to be backed up might be a bit smaller. Handle that
correctly.
Signed-off-by: NeilBrown <neilb@suse.de>
At some points we need to perform 2 backups at once so as to
start the 'double buffering' approach. So rather than assuming
what the next backup should be, example suspend_point and backup
as much as possible up to there.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ We need to clean up the backup file after the reshape finishes.
2/ We need to remove the suspended region and clear the resync
controls after the resync finishes.
Signed-off-by: NeilBrown <neilb@suse.de>
The array_size we need to consider is the largest possible size of the
array, which is a different calculation depending on whether the array
is growing or shrinking.
Signed-off-by: NeilBrown <neilb@suse.de>
'sync_completed' can sometimes have a value which is slightly high.
So round-down relevant values to new-chunk size and that is what we
want.
Subtract from component_size after scaling down rather than before as
that is easier.
Make sure max_progress never goes negative when reshaping backwards.
Signed-off-by: NeilBrown <neilb@suse.de>
The current code is right.
Instead compute where we might eventually need to back up to, and
then compare that to how far we have progressed.
Also move suspend_point up towards where we might need to backup to,
rather than just as far as max_progress - as max_progress can never
exceed where we are currently suspended to.
Signed-off-by: NeilBrown <neilb@suse.de>
It isn't needed as we always work in multiples of full
destination stripes.
Also multiply by 'after' disks, not before.
We can progress until the point we would write then lines up with
where we would read now.
We read now from
array-address: reshape_progress device-address: read_offset
So we write then to
device-address: read_offset array-address: read_offset * after.disks
Signed-off-by: NeilBrown <neilb@suse.de>
The 'blocks' number computed by analyse_change is the number of
blocks that it makes sense to back-up at a time.
It is the smallest number of blocks that is a whole number of
stripes in both the old and the new layout.
However we are also using it as the smallest amount of progress
that can be made at a time, which is wrong as it is always valid
to progress a single stripe in the new layout.
So change 'blocks' to be called 'backup_blocks' to make it more clear.
And pass new_chunk size down so it can be used for 'minimum forward
progress' calculations.
Also set 'stripes' (the amount actually backed up) from the
possibly-scaled 'blocks' number rather than ignoring it and using
backup_blocks.
Finally, get rid of 'read_range' as it isn't used (or needed).
Signed-off-by: NeilBrown <neilb@suse.de>
Once we have called reshape_container or reshape_super we have handed
on the responsibility for unfreezing the array, so Grow_reshape
shouldn't call unfreeze.
Signed-off-by: NeilBrown <neilb@suse.de>
When converting to RAID6, the new layout should match the old
layout, not the RAID6 version of the old layout.
Signed-off-by: NeilBrown <neilb@suse.de>
We want start_reshape to work no matter what the current values
of suspend_lo/suspend_hi are. So initialise suspend_lo very high
as this allows suspend_hi to be set to anything.
Signed-off-by: NeilBrown <neilb@suse.de>
After raid0 reshape is finished backward takeover has to be executed.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When new disks are added array size has to be set by mdadm as array grows.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For external metadata parameters has to be changed via sysfs.
i.e. change of raid_disks requires handshake mdmon<->md (md_allow_write())
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Metadata is not modified by metadata preparation handler.
It has to be read again from array.
There is 2 read required:
1. before 'for' entry to get updated information after reshape_super() call
2. inside 'for' loop to get updated information for every processed array
(it can happen /i.e. imsm case/ that container operation is a set of array operations
and information in metadata is changed after every loop).
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Combine all the non-backing-up code into a single function:
progress_reshape. It is called repeatedly to monitor a
reshape and allow it to happen safely.
Have a single separate function 'child_monitor' which
performs backups of data and calls progress_reshape to
wait for the next backup to be needed.
Signed-off-by: NeilBrown <neilb@suse.de>
Significant rewrite/refactor of Grow_reshape to make it easier to work
with externally-managed-metadata.
This patch it too big, but we'll just have to live with that.
Signed-off-by: NeilBrown <neilb@suse.de>
With externally managed container based metadata, the ->reshape_super
method must choose any spares that are to be added to the array.
They should be prepared so that ->container_content will find them
as spares (disk.state == 0) which are assigned to a slot
(raid_disk >= 0).
We need to take those and add them to the array(s).
Signed-off-by: NeilBrown <neilb@suse.de>
This means that ->manage_reshape will be called with reshape ready to
roll.
Also move the current start_reshape call earlier so that it is before
the other ->manage_reshape call.
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than sprinkling various sysfs setting around, put them all
in one place. This will make implementing ->manage_reshape easier.
This changes behaviour slightly.
Previously we would not set 'sync_action' to 'reshape' until we were
ready for the process to start. Now we set sync_max to zero and set
sync_action to 'reshape' at that time. When we want reshape to
actually start we advance sync_max.
Signed-off-by: NeilBrown <neilb@suse.de>
The two places that this was done were different. The original was
most correct, thought it used odisks rather than odata.
So fix that and make them both use the same calculation.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ When we sunc_metadata, we must reset ->update_tail else
future metadata updates might go direct to the device bypassing
mdmon.
2/ When converting to an array with redundancy so we can add disks
it is neater to sync_metadata before starting mdmon rather that
artificially setting update_tail early.
Signed-off-by: NeilBrown <neilb@suse.de>
Before we freeze a container in preparation for growing a subarray, we
need to be sure all the subarrays are idle.
This test is racy as recovery could start at any moment following a
failure. However it is still useful as it stops us from even trying
to start a reshape while a reshape or recovery is active.
Signed-off-by: NeilBrown <neilb@suse.de>
Growing an array when there aren't enough spares can make the array
degraded. This works but might not be what is wanted.
So warn the user in this case and require a --force to go ahead
with the reshape.
Signed-off-by: NeilBrown <neilb@suse.de>
Sometimes wait_backup() omits transition from reshape to idle state
and mdadm seams to be hung. So check the 'complete' count
*before* waiting rather than only after.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When wait_reshape() function starts it can occurs that reshape is
finished already, before wait_reshape() start. This can lead to wait
for change state inside this function for a long time. To avoid this
before wait we should test if finish conditions are not reached
already.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Move opening backup file to the function for future reuse during
container reshape.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: NeilBrown <neilb@suse.de>
Though not having the proper backup file can cause data corruption, it
is not enough to justify not being able to start the array at all.
So allow "--invalid-backup" to be specified which says "just continue
even if a backup cannot be restored".
Signed-off-by: NeilBrown <neilb@suse.de>
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.
Signed-off-by: NeilBrown <neilb@suse.de>
number of backup blocks evaluation is put in to function for code reuse.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
fd handles table creation is put in to function for code reuse.
In manage_reshape(), child_grow() function from Grow.c will be reused.
To prepare parameters for this function, code from Grow.c can be
reused also.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Until now Raid10->Raid0 takeover was possible only if all the mirrors
where removed before md starts the takeover. Now mdadm, when
performing Raid10->raid0 takeover, will remove all unwanted mirrors
from the array before actual md takeover is called.
Signed-off-by: Maciej Trela <maciej.trela@intel.com>
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When growing the number of raid disks the reshape process will promote
container-spares to subarray-spares (later the kernel promotes them to
subarray-members in raid5_start_reshape()). The automatic spare
promotion that mdmon performs upon seeing a degraded array must be
disabled until the reshape process has been initiated. Otherwise, mdmon
may start a rebuild before the reshape parameters can be specified.
In the external case we arrange for the monitor to be blocked, and
turn off the safemode delay.
Mdmon is updated to check sync_action is not frozen before initiating
recovery.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
In the native metadata case Grow_reshape() and the kernel validate what
reshapes are possible / supported and the kernel handles all the metadata
updates. In the external case the metadata format may have specific
constraints above this baseline. External formats also introduce the
constraint of only permitting some reshapes at container scope versus subarray
scope. For exmaple imsm changes to 'raiddisks' must be applied to all arrays
in the container.
This operation assumes that its 'st' parameter has been obtained from
super_by_fd() (such that st->subarray is up to date), and that a snapshot of
the metadata has been loaded from the container.
Why a new method, versus extending an existing one?
->validate_geometry: this routine assumes it is being called from Create(),
adding reshape complicates the cases that this routine needs to handle. Where
we find that checks can be shared between the two cases those routines
refactored into common code internal to the metadata handler, i.e. no need to
provide a unified external interface. ->validate_geometry() also does not
expect to update the metadata.
->update_super: this is meant to update single fields at Assembly() and only at
the container scope. Reshape potentially wants to update multiple fields at
either container or subarray scope.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
If the user does not specify a layout, don't skip asking about retaining
the non-standard raid6 layout which may be implicitly changed.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Going through the Grow api found some local routines that could be
marked static.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Rather than hiding this in the 'st', return it explicitly.
In the one case we still need it, copy it into st where needed.
This will disappear in a future patch.
Signed-off-by: NeilBrown <neilb@suse.de>
To accurately detect when an array has been split and is now being
recombined, we need to track which other devices each thinks is
working.
We should never include a device in an array if it thinks that the
primary device has failed.
This patch just allows get_info_super to return a list of devices
and whether they are thought to be working or not.
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>
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>
...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>
A recent change move the sysfs_read call away from the check that it
succeeded. This patch moves the check back next to the sysfs_read
call.
Signed-off-by: NeilBrown <neilb@suse.de>
Chunks aren't particularly big, but when you could them in bytes
and multiply them together (as we do for calculating the backup
size for 'grow') they can overflow a 32bit int.
So group the division by 512 more closely with the
chunk size so were would need 30Meg chunks to come close to
overflowing 32bits.
Signed-off-by: NeilBrown <neilb@suse.de>
When checking if the new chunk size fit in the component size
we were confusing sectors and K, and so getting it wrong.
Signed-off-by: NeilBrown <neilb@suse.de>
When building mdadm.O2, set _FORTIFY_SOURCE to get more
warnings, and also build mdmon.O2 to find warnings in that
code too.
Then fix the warnings.
Suggested-by: Luca Berra <bluca@comedia.it>
Signed-off-by: NeilBrown <neilb@suse.de>
As backup file has a timestamp which is updated quite separately
from the metadata timestamp. They should be largely in-sync but
sometimes are not.
So be more generous in the check, and allow it to be over-ridden
by an environment variable.
Signed-off-by: NeilBrown <neilb@suse.de>
If a bitmap exists on an array, then current kernels cannot grow
that array.
So when we try to grow an array, test for EBUSY and if a bitmap is
present, report that the bitmap needs to be removed.
Resolves-Debian-Bug: 534571
Signed-off-by: NeilBrown <neilb@suse.de>
These were never supposed to be released, and due
to a type issue they cause compile problems on
some architectures.
Resolves-Debian-Bug: 567167
Signed-off-by: NeilBrown <neilb@suse.de>
As array.size is 32bit we need to prefer the 'component_size'
read from sysfs when that is available.
Grow wasn't always suitably careful.
Signed-off-by: NeilBrown <neilb@suse.de>
array.size is only 32bit so it is not safe to multiply it
up before casting to (long long).
Actually, we shouldn't be using array.size here at all, but that
will get fixed in a subsequent patch.
Reported-by: Andrew Burgess <aab@cichlid.com>
Signed-off-by: NeilBrown <neilb@suse.de>
A change the reduces the size of an array always happens
before any other change. So it can cause data to be lost.
By themselves these changes are reversible. But once another
change has started, the data would be permanently lost.
So recommend data integrity be checked between a size change
and any other change.
Signed-off-by: NeilBrown <neilb@suse.de>
2.6.31 has a bug which can lead to unsafe reshaping.
So only allow a reshape with 2.6.32.
When the required fixed get into 2.6.31.y, this can be relaxed
slightly
Signed-off-by: NeilBrown <neilb@suse.de>
We were using ->component_size while it hadn't been set.
This effectively meant that 'blocks' wasn't multiplied by
16 and reshape was even slower than it should have been.
Signed-off-by: NeilBrown <neilb@suse.de>
If an array goes degraded during reshape, we need to
adjust the devices we read from so as not to back up
stale data.
Signed-off-by: NeilBrown <neilb@suse.de>
The 'arraystart' is in sectors while restore_stripes requires
bytes, so we need a conversion.
Without this, backups get restored to the wrong offset.
Reported-by: "KueiHuan Chen" <kueihuan.chen@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Originally the backup-metadata was only written once at the
start of a raid5 reshape that made the array bigger. So we only
set the mtime once.
Now that we can be writing metadata continually during an in-place
reshape, we need to update the mtime more often.
Also, allow the metadata mtime to be slightly in advance of the
array mtime. Normally the difference will be less than a second,
so 10 minutes should be plenty. This guards against an old backup
file being used to restart an array. but starting two reshapes in the
10 minutes is sufficiently unlikely, and the possibility of an
accident is already sufficiently small, that 10 minutes is probably
fine.
Thanks to Guy Martin <gmsoft@tuxicoman.be> for discovering and
reporting that .mtime wasn't being updated properly.
Signed-off-by: NeilBrown <neilb@suse.de>
FIXME this is wrong . what direction does reshape_position move?
If the device count in an array is shrinking, the critical
region is different so the tests need to be different when
restarting.
Signed-off-by: NeilBrown <neilb@suse.de>
On small (test) arrays, multiplying by 16 can make the 'chunk' size
larger than half the array, which is a problem.
Signed-off-by: NeilBrown <neilb@suse.de>
The last time wait_backup is called, it might see reshape
finish and so return an error indicator.
But this is not an error, and we must go ahead and prepare
the array for full access.
Signed-off-by: NeilBrown <neilb@suse.de>
1/ allow --size to be given with 'G' or 'T' suffix.
2/ allow size to exceed 32bits, and in that case write through sysfs.
Signed-off-by: NeilBrown <neilb@suse.de>
This allows the layout to be parsed after the current level of the
array is know, so that the level doesn't need to be given (otherwise
pointlessly) on the command line.
Signed-off-by: NeilBrown <neilb@suse.de>
For short reshapes the kernel may be done before mdadm can check that
progress has passed the critical section.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If an array reshape completed within 1 second, then --grow will not
notice that it has finished and will keep waiting for the critical
section to pass.
So be more cautious in the test.
Signed-off-by: NeilBrown <neilb@suse.de>
Since we introduced O_DIRECT for device access we need
properly aligned buffers and IO requests. The reshape code
missed out on the conversion.
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>
Using buffered IO risks non-atomic updates to parts of the
device that we don't actually want to write to. This isn't in
general safe.
So switch to O_DIRECT for all that IO and make sure we have
properly aligned buffers.
The last release broke the ability to assemble an array that
was in the middle of a reshape.
This patch adds code to test if the critical section needs
to be restored or not so that - if we have failed to restore it,
we know whether to fail or not.
Make sure that if --assemble find an array in the critical region
of a reshape, and cannot find the critical data to restart the
reshape, it gives an error message.
The new superblock needs to have a new disk.number. This is a bit of a hack...
Fix handling of negative bitmap offsets on 64bit hosts.
The bitmap offset is a signed 32bit number, so casting to (long)
isn't sufficient. We must cast to (int32_t).
Fix various problems with --grow --add for linear.
The code to add a drive to a live linear array had never
been tested properly and so was buggy. This tidies it up
and means that the new regression-test passes.
Depending on the size of the array we reserve space for up to 128K
of bitmap, and we use it where possible.
When hot-adding to a version 1.0 we can still only use the 3K at the
end though - need a sysfs interface to improve that.
If a small chunksize is requested on Create, we don't auto-enlarge
the reserved space - this still needs to be fixed.
From: Luca Berra <bluca@vodka.it>
glibc 2.4 is pedantic on ignoring return values from fprintf, fwrite and
write, so now we check the rval and actually do something with it.
in the Grow.c case i only print a warning, since i don't think we can do
anything in case we fail invalidating those superblocks (is should never
happen, but then...)
Signed-off-by: Neil Brown <neilb@suse.de>
When creating a file bitmap, choose a default size that
results in fewer than 2^21 chunks. Without this kmalloc
failure in the kernel becomes likely.
Signed-off-by: Neil Brown <neilb@suse.de>
To support resizing an array without a spare, mdadm now understands
--backup-file=
which should point to a file for storing a backup of critical data.
This can be given to --grow which will create the file, or
--assemble which will restore from the file if needed.
Signed-off-by: Neil Brown <neilb@suse.de>
- report Intent Bitmap in --detail
- report internal bitmap in --examine
- pass' --force through to --grow --bitmap
- support v.large arrays in --grow --bitmap
Signed-off-by: Neil Brown <neilb@suse.de>
Support "--build"ing arrays with bitmaps.
hot-removal of bitmaps
--re-add of drives recently removed.
assorted extra tests
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Currently this includes
--write-behind to set level of write-behind supported
--write-mostly to flag devices as write-mostly.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
This includes:
adding --metadata= option to choose metadata format
adding metadata= word to config file.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
This allows for larger device number if glibc supports
it (requires 2.3.3).
Also fail before creating larger device number if glibc
support isn't present.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>