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.
There is still a problem: If array is partially assembled and started
read-only, the last device doesn't get added properly. Probably a kernel
problem.
This did not work before as we couldn't mark it clean as there would
be some parity blocks out of sync, and raid6 will not assemble a
dirty degraded array.
So make such arrays doubly degraded (the last device becomes a spare)
and clean.
array.size is 32bits and counts K. So for arrays with
more than 4Terrabytes, it can overflow.
The correct number can be read from sysfs, but there are still
a few places that use array.size and risk truncation. What is worse.
they compare a number of kilobytes with a number of sectors !!
So use get_component_size() to read the sysfs information, and be
more consistent about units.
Some kernel versions don't put a space between 'active' and '(auto-read-only)'
in /proc/mdstat. This causes a parsing problem leaving 'level' set to
NULL which causes a crash.
So synthesise a space there if it is missing, and check for 'level' to
be NULL and don't de-ref if it is.
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.
Commit a40b4fe introduced a temporary supertype variable tst, instead of
manipulating st directly. However, it was forgotton to pass &tst into the
recursive load_super1 call, causing an infinite recursion.
Signed-off-by: martin f. krafft <madduck@debian.org>
another small step for better klibc support, glibc compile tested.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Neil Brown <neilb@suse.de>
When load_super1 is trying to see which sub-version of v1 superblock
is present, failure will cause it to clear st->ss, which is not good.
So use a temporary 'super_type' for the 'test if this version works'
calls, then copy that into 'st' on success.
sys/dir.h is an old BSD'ism, include dirent directly.
small step for better klibc support.
compile tested against glibc.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Neil Brown <neilb@suse.de>
klibc still misses a lot functionality to let mdadm link against,
this small step helps to get to the real trouble.. :)
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Neil Brown <neilb@suse.de>
Fixes Debian Bug 442874
When we discover that we can 're-add' a drive, we forget to check the
write-mostly flag.
This highlights the fact that you cannot turn 'off' the write-mostly
flag at this point. I wonder if that is a problem...
From: Iustin Pop <iusty@k1024.org>
There are many questions on the mailing list about the RAID1 read
performance profile. This patch adds a new paragraph to the RAID1
section in md.4 that details what kind of speed-up one should expect
from RAID1.
Signed-off-by: Iustin Pop <iusty@k1024.org>
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.
When adding new disk to an array, don't reserve so much bitmap
space that the disk cannot store the required data. (Needed when
1.x array was created with older mdadm).
Bill Nottingham
Neil Brown
Jérémy Bobbio
martin f. krafft
maximilian attems
Iustin Pop