| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
In particular, if the relevant bitmap method is NULL, don't try to
call it, print an error instead.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
|
|
|
| |
Recent fix to check lseek64 return status got it badly wrong.
It doesn't return 0 on success!!
Fix it.
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>
|
|
|
|
|
|
| |
Warning only appears with -O2, but is invalid.
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>
|
|
|
|
|
|
|
| |
- I forgot to write the send backup-super-block on spares.
- I wasn't adding the data_offset to an offset
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
| |
Another missed sectors->bytes conversion.
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>
|
|
|
|
|
|
| |
otherwise we exit with the array frozen.
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>
|
|
|
|
|
|
|
|
| |
The bigger the backup is, the fast it goes to some extend.
16Meg is fairly arbitrary
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>
|
|
|
|
|
|
|
| |
2.6.31 has some bugs with restarting a RAID5 reduction, so
refuse to try unless at least 2.6.32.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
| |
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
|
|
|
|
| |
Thus we weren't checking the uuid 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>
|
|
|
|
|
|
|
| |
We do O_DIRECT io in bsb2, so it must be aligned
properly. Easiest if it is static.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|\
| |
| |
| |
| | |
Conflicts:
mdadm.8
|
| |
| |
| |
| |
| |
| | |
Also removed 'paper' addresses.
Signed-off-by: NeilBrown <neilb@suse.de>
|
| | |
|
| |
| |
| |
| | |
UNFINISHED
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Grow.c
mdadm.h
sysfs.c
Due to independent fixes for the "mdadm hangs if reshape finishes too quickly"
problem.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
Create.c
Manage.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| | |
There was a kernel bug with stopping and restarting
raid5 recently. So add a test to check for it.
|
|/
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Sure, mdinfo is bigger, but having a uniform structure for lots of things
will make life easier.
|
|
|
|
|
| |
there is needless duplicatiion between mdinfo and sysdev, so discard
the latter.
|
|
|
|
|
| |
We used to use the major/minor numbers, but that isn't sufficient
any more, so pass the fd, and possibly check 'text' version.
|
|
|
|
| |
It is now in the 'supertype'
|
|
|
|
| |
The 'superblock' will be moved into this structure soon.
|
|
|
|
|
|
| |
As the metadata handler allocates the superblock, it should free it
too. DDF will have a more complex 'superblock' which needs more complex
freeing.
|